Skip to main content
Stashing lets an actor temporarily buffer messages instead of processing them. Use it when the actor cannot handle certain messages in its current state (e.g., waiting for a resource, or during a behavior transition).

Enabling stashing

Pass WithStashing() as a SpawnOption:
Enabling stashing
Without WithStashing(), calls to Stash, Unstash, or UnstashAll record ErrStashBufferNotSet.

API

  • ctx.Stash: Buffer the current message. It will not be processed until unstashed. The message is moved to a side buffer; the actor continues with the next message.
  • ctx.Unstash: Take the oldest stashed message and send it to the actor again. It is appended to the mailbox, so it is handled after the messages already queued.
  • ctx.UnstashAll: Send every stashed message to the actor again, oldest first, behind the messages already queued.
Stashed messages are processed in FIFO order when unstashed.

When to use

  • Behavior transitions: Stash messages you cannot handle in the current behavior; unstash after switching.
  • Conditional processing: Stash messages until a condition is met (e.g., dependency ready, lock acquired).
  • Reentrancy: With StashNonReentrant mode, in-flight Ask requests cause user messages to be stashed automatically until the request completes.

Example

A gate actor that buffers requests until opened:
Example

Stash size

pid.StashSize() returns the number of messages currently in the stash. Useful for metrics or backpressure.

Stash and lifecycle

A restart keeps the stash. Messages the actor stashed on its own stay stashed for the new incarnation to unstash when it decides to; messages a StashNonReentrant request had stashed are replayed to the new incarnation after PostStart (see Reentrancy). A stop drops the stashed messages with the mailbox: an actor restarted later under the same name starts with an empty stash and can stash again.