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. Eachawait 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.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: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
- Create an awakeable - Get a unique ID and awaitable result
- Send the ID externally - Pass the awakeable ID to your external system
- Wait for result - Your handler suspends until the external system responds
Serialization
Serialization
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:Via HTTP API
External systems can complete awakeables using Restate’s HTTP API: Resolve with data: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.