Skip to content

[Security] The unbounded system-queue drain is a starvation surface, and only the queue is documented #1633

Description

@pathosDev

Mailbox.enqueueSystem is deliberately uncapped — supervision and lifecycle messages must never be dropped, and no bound reaches it, a subclass's own included. That decision is right and is now documented on the mailboxes page in both languages (#794).

The half that decision does not answer: the drain loop takes the whole system queue before it returns to user messages, so a sender that can mint system messages faster than the cell drains them starves the user queue for as long as it keeps going. Nothing bounds the turn, only the queue.

In-process code can do this trivially; whether a remote peer can depends on which system messages a transport will deliver, which is worth establishing rather than assuming.

What would close it: a per-turn budget on the system drain — take at most N system messages, then yield to the user queue and come back — which keeps the no-drop guarantee while bounding the turn. ActorCell.run already has the shape for it; the JSDoc there points at Mailbox.enqueueSystem for the absent budget.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    priority: mediumUseful, not urgentproduction-goalBlocks or defines the path to production readinesssecuritySecurity-relevant — see severity label for impact tierseverity: mediumModerate impact or requires specific conditions

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions