Available state change hooks
| Type | Flow | Task | Description |
|---|---|---|---|
on_completion | ✓ | ✓ | Executes when a flow or task run enters a Completed state. |
on_failure | ✓ | ✓ | Executes when a flow or task run enters a Failed state. |
on_cancellation | ✓ | - | Executes when a flow run enters a Cancelling state. |
on_crashed | ✓ | - | Executes when a flow run enters a Crashed state. |
on_running | ✓ | ✓ | Executes when a flow or task run enters a Running state. |
Note that the
on_rollback hook for tasks is not a proper state change hook but instead
is a transaction lifecycle hook.
Rollback hooks accept one argument representing the transaction for the task.Send a notification when a workflow run fails
To send a notification when a flow or task run fails, you can specify aon_failure hook.
on_failure hook will not run until all retries have completed and the flow run enters a Failed state.
State change hooks execute client sideState change hooks run in the same process as your workflow and execution cannot be guaranteed. For more robust execution of logic in response to state changes, use an Automation.
Execute code when a task starts running
Theon_running hook executes when a task enters a Running state, before the task body executes. This is useful for logging, metrics, or setting up runtime state:
on_running hooks execute synchronously before the task body runs. If your hook takes 10 seconds, the task waits 10 seconds before starting.
When retries are configured, on_running hooks fire on each retry attempt, including the initial run. For example, a task configured with retries=2 will trigger its on_running hooks up to three times: once on the initial run and once for each retry attempt.
Pass kwargs to state change hooks
You can compose the with_options method to effectively pass arbitrary **kwargs to your hooks: