Skip to main content
Handlers sometimes need to receive input after their invocation has started. Restate provides three durable coordination primitives for this: All three survive retries and process restarts. When an invocation has nothing else to do while waiting, Restate can suspend it and resume it when the next result arrives.

Signals

Signals deliver durable notifications to an ongoing invocation. A signal is identified by the target invocation ID and a name. The same named signal can be resolved multiple times. Each await of the signal receives the next resolution.

Wait for a signal

Resolve a signal

To resolve a signal, you need the target invocation ID. You can get it from a call or send handle, or read the current invocation’s ID from the handler request and pass it to the sender.
Use reject() instead of resolve() to deliver a terminal failure to the waiting invocation.

Wait for repeated signals

A signal can be resolved multiple times. Repeatedly call the signal API to wait for the next resolution of a named signal:
A signal can arrive before or after the invocation starts waiting for it. Restate stores each resolution durably until the invocation receives it.

Awakeables

An awakeable is a convenient shorthand for a one-shot signal. It has a generated unique ID that an external system can resolve or reject through Restate, similar to a task token.

Creating and waiting for awakeables

  1. Create an awakeable - Get a unique ID and awaitable result
  2. Send the ID externally - Pass the awakeable ID to your external system
  3. Wait for result - Your handler suspends until the external system responds
To customize serialization, visit the docs.
Note that if you wait for an awakeable in an exclusive handler in a Virtual Object, all other calls to this object will be queued.

Resolving or rejecting an awakeable

External processes complete awakeables in two ways:
  • Resolve with success data → handler continues normally
  • Reject with error reason → throws a terminal error in the waiting handler

Via SDK (from other handlers)

Resolve:
Reject:

Via HTTP API

External systems can complete awakeables using Restate’s HTTP API: Resolve with data:
Reject with error:

Workflow promises

A workflow promise belongs to a workflow key and has a logical name. It can be resolved or rejected once, and its result can be retrieved multiple times by all handlers of the workflow during the workflow retention period. Use this to:
  • Have shared handlers interact with the workflow run handler
  • Have one or multiple handlers wait for events emitted by the run handler
After a workflow’s run handler completes, other handlers can still be called for up to 24 hours (default). The results of resolved workflow promises remain available during this time. Update the retention time via the service configuration.

Get and wait for a workflow promise

Create a workflow promise key:
Wait for a workflow promise by name:
Your workflow can suspend until the workflow promise is resolved or rejected.

Resolve or reject a workflow promise

Resolve or reject it from any handler of the same workflow:

Complete workflow example

Choose a primitive

Use a signal when another Restate invocation needs to send one or more notifications to an invocation that is already running. Use an awakeable when an external system needs a unique, one-shot callback token that it can complete through Restate’s HTTP API. Use a workflow promise when the value belongs to a workflow and should remain retrievable by any of its handlers for the workflow retention period. For long waits, combine the primitive with a durable timer to implement a timeout. Handle rejection when the sender can report a terminal failure.