Cancellation
Running workflows can be cancelled through the CLI or API, with the engine propagating cancellation to all in-flight steps.
Cancelling a Run
Cancel a running workflow by run ID:
dagnats run cancel <run-id>Or via the REST API:
curl -X POST http://localhost:8080/v1/runs/<run-id>/cancelThe engine publishes a workflow.cancelled event to the history stream. The run status transitions to cancelled.
Propagation
When a run is cancelled, the engine:
- Marks the run status as
cancelled - Cancels all pending steps (not yet dispatched) by setting them to
cancelled - Cancels all queued steps by letting their NATS messages expire (AckWait timeout)
- In-flight steps that are already running on a worker continue until the worker checks for cancellation or the step’s AckWait expires
Workers do not receive an explicit cancellation signal mid-execution. Instead, the next time the worker attempts to publish a result event, the engine ignores events for cancelled runs. This design avoids the complexity of distributed cancellation protocols.
Event-Driven Cancellation
The CancelOn field on WorkflowDef specifies events that automatically cancel a running workflow:
wf := dag.NewWorkflow("deploy").
WithCancelOn(dag.CancelOn{
Event: "event.deploy.rollback",
Match: dag.Match{
Left: "env",
Right: "env",
},
Timeout: 1 * time.Hour,
})When a matching event arrives on the EVENTS stream, the engine cancels the run without manual intervention. The Match field correlates the event payload against the run input – in this example, only a rollback event for the same env value cancels the run.
Graceful Shutdown
When the dagnats serve process receives a shutdown signal (SIGTERM/SIGINT), it performs a graceful shutdown:
- Stops accepting new workflow runs
- Drains in-flight NATS subscriptions
- Waits for active workers to finish current tasks (bounded by AckWait)
- Persists final state to KV
Runs that were in progress during shutdown resume automatically when the server restarts – the orchestrator replays from the WORKFLOW_HISTORY stream and picks up where it left off.
Child Workflow Cancellation
Cancelling a parent workflow propagates to child workflows spawned by sub-workflow steps. The engine cancels child runs recursively (bounded by max nesting depth of 3).
Related Pages
- Timeouts – automatic cancellation on deadline
- Error Handling – failure handling after cancellation
- Concurrency Limits – preventing overload