Amazon Simple Workflow Service Signals - Amazon Simple Workflow Service
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China.

Amazon Simple Workflow Service Signals

Signals enable you to inform a workflow execution of external events and inject information into a workflow execution while it is running. Any program can send a signal to a running workflow execution by calling the SignalWorkflowExecution API. When a signal is received, Amazon SWF records it in the workflow execution's history as WorkflowExecutionSignaled event and alerts the decider by scheduling a decision task.


An attempt to send a signal to a workflow execution that isn't open results in SignalWorkflowExecution failing with UnknownResourceFault.

In this example, the workflow execution is sent a signal to cancel an order. SignalWorkflowExecution {"domain": "867530901", "workflowId": "20110927-T-1", "runId": "f5ebbac6-941c-4342-ad69-dfd2f8be6689", "signalName": "CancelOrder", "input": "order 3553"}

If the workflow execution receives the signal, Amazon SWF returns a successful HTTP response similar to the following. Amazon SWF will generate a decision task to inform the decider to process the signal.

HTTP/1.1 200 OK Content-Length: 0 Content-Type: application/json x-amzn-RequestId: bf78ae15-3f0c-11e1-9914-a356b6ea8bdf

Sometimes you might want to wait for a signal. For example, a user could cancel an order by sending a signal, but only within one hour of placing the order. Amazon SWF doesn't have a primitive to enable a decider to wait for a signal from the service. Pause functionality needs to be implemented in the decider itself. In order to pause, the decider should start a timer, using the StartTimer decision, which specifies the duration for which the decider will wait for the signal while continuing to poll for decision tasks. When the decider receives a decision task, it should check the history to see if either the signal has been received or the timer has fired. If the signal has been received, then the decider should cancel the timer. However, if instead, the timer has fired, then it means that the signal did not arrive within the specified time. To summarize, in order to wait for a specific signal, do the following.

  1. Create a timer for the amount of time the decider should wait.

  2. When a decision task is received, check the history to see if the signal has arrived or if the timer has fired.

  3. If a signal has arrived, cancel the timer using a CancelTimer decision and process the signal. Depending on the timing, the history may contain both TimerFired and WorkflowExecutionSignaled events. In such cases, you can rely on the relative order of the events in the history to determine which occurred first.

  4. If the timer has fired, before a signal is received, then the decider has timed out waiting for the signal. You can fail the execution or do whatever other logic is appropriate to your use case.