Sending Signals, Queries, & Updates
This section will help you write clients that send messages to Workflows which includes:
Sending Signals​
You can send Signals from any Temporal Client, the Temporal CLI, or you can Signal one Workflow to another.
You can also Signal-With-Start to lazily initialize a Workflow while sending a Signal.
Send a Signal from a Temporal Client or the CLI​
Send a Signal using the Temporal CLIfeature-guide
Send Signals with the Go SDKfeature-guide
Send Signals with the Java SDKfeature-guide
Send Signals with the PHP SDKfeature-guide
Send Signals with the Python SDKfeature-guide
Send Signals with the TypeScript SDKfeature-guide
Send Signals with the .NET SDKfeature-guide
Send a Signal from one Workflow to another​
- Send Signals from Workflows with the Go SDKfeature-guide
- Send Signals from Workflows with the Java SDKfeature-guide
- Send Signals from Workflows with the PHP SDKfeature-guide
- Send Signals from Workflows with the Python SDKfeature-guide
- Send Signals from Workflows with the TypeScript SDKfeature-guide
- Send Signals from Workflows with the .NET SDKfeature-guide
Signal-With-Start​
Signal-With-Start is a great tool for lazily initializing Workflows. When you send this operation, if there is a running Workflow Execution with the given Workflow Id, it will be Signaled. Otherwise, a new Workflow Execution starts and is immediately sent the Signal.
- Signal-With-Start using the Go SDKfeature-guide
- Signal-With-Start using the Java SDKfeature-guide
- Signal-With-Start using the PHP SDKfeature-guide
- Signal-With-Start using the Python SDKfeature-guide
- Signal-With-Start using the TypeScript SDKfeature-guide
- Signal-With-Start using the .NET SDKfeature-guide
Sending Updates​
- Available in Go SDK since v1.28.0
- Available in Java SDK since v1.25.0
- Available in Python SDK since v1.7.0
- Available in .NET SDK since v0.1.0-beta2
- Available in TypeScript SDK since v1.11.0
- Available in PHP SDK since v2.11.0
To use the Workflow Update feature in versions prior to v1.25.0, it must be manually enabled.
Set the frontend.enableUpdateWorkflowExecution and frontend.enableUpdateWorkflowExecutionAsyncAccepted dynamic config values to true.
For example, with the Temporal CLI, run these commands:
temporal server start-dev --dynamic-config-value frontend.enableUpdateWorkflowExecution=true
temporal server start-dev --dynamic-config-value frontend.enableUpdateWorkflowExecutionAsyncAccepted=true
Updates can be sent from a Temporal Client or the Temporal CLI to a Workflow Execution. This call is synchronous and will call into the corresponding Update handler. If you’d rather make an asynchronous request, you should use Signals.
In most languages (except Go), you may call executeUpdate to complete an Update and get its result.
Alternatively, to start an Update, you may call startUpdate and pass in the Workflow Update Stage as an argument. You have two choices on what to await:
- Accepted - wait until the Worker is contacted, which ensures that the Update is persisted. See Update Validators for more information.
- Completed - wait until the handler finishes and returns a result. (This is equivalent to
executeUpdate.)
The start call will give you a handle you can use to track the Update, determine whether it was Accepted, and ultimately get its result or an error.
If you want to send an Update to another Workflow such as a Child Workflow from within a Workflow, you should do so within an Activity and use the Temporal Client as normal.
There are limits on the total number of Updates that may occur during a Workflow Execution run, and also on the number of concurrent in-progress Updates that a Workflow Execution may have. Use Update Validators and Update IDs to stay within the system limits in both Cloud and Self-Hosted.
- Send Updates in Gofeature-guide
- Send Updates in Javafeature-guide
- Send Updates in PHPfeature-guide
- Send Updates in Pythonfeature-guide
- Send Updates in Typescriptfeature-guide
- Send Updates in .NETfeature-guide
Update-With-Start​
In Public Preview in Temporal Cloud.
Minimum Temporal Server version Temporal Server version 1.26
Update-With-Start sends an Update that checks whether an already-running Workflow with that ID exists. If it does, the Update is processed normally. If not, it starts a new Workflow Execution with the supplied ID, and immediately processes the Update.
Update-With-Start is great for latency-sensitive use cases:
- Lazy Initialization - Instead of making separate Start Workflow and Update Workflow calls, Update-With-Start allows you to send them together in a single roundtrip. For example, a shopping cart can be modeled using Update-With-Start. Updates let you add and remove items from the cart. Update-With-Start lets the customer start shopping, whether the cart already exists or they've just started shopping. It ensures the cart, modeled by a Workflow Execution, exists before applying any Update that changes the state of items within the cart.
- Early Return - Using Update-With-Start you can begin a new Workflow Execution and synchronously receive a response, while the Workflow Execution continues to run to completion. For example, you might model a payment process using Update-With-Start. This allows you to send the payment validation results back to the client synchronously, while the transaction Workflow continues in the background.
Unlike Signal-with-Start - Update-With-Start is not atomic. If the Update can't be delivered, for example, because there's no running Worker available, a new Workflow Execution will still start. The SDKs will retry the Update-With-Start request, but there is no guarantee that the Update will succeed.
- Update-With-Start with the Go SDKfeature-guide
- Update-With-Start with the Java SDKfeature-guide
Sending Queries​
Queries can be sent from a Temporal Client or the Temporal CLI to a Workflow Execution--even if this Workflow has Completed. This call is synchronous and will call into the corresponding Query handler. You can also send a built-in "Stack Trace Query" for debugging.
- Send a Query using the Temporal CLIfeature-guide
- Send a Query with the Go SDKfeature-guide
- Send a Query with the Java SDKfeature-guide
- Send a Query with the PHP SDKfeature-guide
- Send a Query with the Python SDKfeature-guide
- Send a Query with the TypeScript SDKfeature-guide
- Send a Query with the .NET SDKfeature-guide
Stack Trace Query​
In many SDKs, the Temporal Client exposes a predefined __stack_trace Query that returns the call stack of all the threads owned by that Workflow Execution.
This is a great way to troubleshoot a Workflow Execution in production.
For example, if a Workflow Execution has been stuck at a state for longer than an expected period of time, you can send a __stack_trace Query to return the current call stack.
The __stack_trace Query name does not require special handling in your Workflow code.
Stack Trace Queries are available only for running Workflow Executions.