Skip to content

Waiting for External Events

A Flux Service has the capability to pause its execution when it needs to. This is useful when your workflow might need to wait for a response before continuing to another state. To do this, you can mark a state as waiting. A waiting state is required to have at least one transition. When a waiting state is executed, the service is immediately paused. It can be resumed by sending an event to the Flux Service. We call this type of event an external event.

An external event contains the following properties:

  • event - tells the waiting state what transition to invoke.
  • inputs - values to set to the waiting state's inputs.
  • tags - allows selective sending of events to resume multiple Flux Services.

$fluxEvent becomes a state input when setting a state to waiting. This is because a waiting state is transitioned based on the value of event which is then mapped to $fluxEvent. When the external event is accepted, the waiting state's action is executed.

Unlike regular states, inputs of a waiting state are injected from an external event. These are validated as well. If any validation error occurs, the Flux Service will ignore the event and will continue waiting. This is a fail-fast feature and prevents a Flux Service from accidentally resuming its execution due to invalid inputs.

To demonstrate waiting states, create a Flux containing a three states, one of which transitions to two other states similar to the following:

Before waiting state

Notice that the starting state has a validation error. This is because $fluxEvent is not set. Let's see what happens when we set this state to waiting. To mark a state as waiting, right click the state and click Toggle Waiting. You will know that a state is waiting when it has a hand icon on it.

Setting waiting state

Setting waiting state

Notice that the validation error for waiting state is now gone. If you examine the state on the Mapper view, $fluxEvent is now an input property instead of an output. Since a waiting state requires external event to resume its execution, $fluxEvent will be based on the external event.

Run the service for now and next, we'll resume it by sending an external event.

Sending an External Event

Sending an external event to a Flux Service can be done via the Flux REST API or Coder.

To a Single Flux Service

In order to resume a specific Flux Service, you need to know its ID. It can be retrieved from the response after running the Flux Service. Fortunately, Coder provides a dialog that sends external events which is useful for development purposes.

To access the dialog, right click your TORO Integrate instance and click Flux > Send Flux Event.

Sending external event

Alternative method

A quick way to send external event is to right click a transition and click Send Flux Event. This will populate the properties of the external event as well as the inputs from the waiting state.

To access the dialog, right click any blank space under Coder Navigator and click Flux > Send Flux Event.

Sending external event

To Multiple Flux Services

You can also send an external event to multiple Flux Services with the use of tags. Any service will accept the event if it satisfies all these conditions:

  1. It is currently waiting.
  2. It is tagged with at least one of the specified tags.
  3. Its current state has a transition of the event.
  4. No validation error occurred when inputs of the external event are injected.

If any of these conditions are not met, the event will be ignored.