Ironflow Cancel Flow

Ironflow Cancel Flow A workflow diagram generated by Archify. 01 / Caller 02 / Ironflow server 03 / Executors EX / Refused Commit to the DB Tell the executors CancelRun · run ID + version · Caller › Commit to the DB CancelRun run ID + version State guard · is the run still live? · Ironflow server › Commit to the DB State guard is the run still live? Read, validate, CAS · retries at fresh version · Ironflow server › Commit to the DB Read, validate, CAS retries at fresh version Mark run terminal · status, cause, ended_at · Ironflow server › Commit to the DB · claim released Mark run terminal status, cause, ended_at claim released CANCEL stream · msg-id dedupe · Ironflow server › Tell the executors · best effort CANCEL stream msg-id dedupe best effort Push executor · re-reads the run · Executors › Tell the executors Push executor re-reads the run Pull worker · gets the signal · Executors › Tell the executors Pull worker gets the signal Refused · already terminal · Refused › Commit to the DB Refused already terminal version matched still live terminal already then signal status read before each step cancel.run.{runID} cancel Legend Server step Guard Best-effort signal Durable state Caller / executor

The DB is the source of truth

  • • A CAS on runs.version commits it; a conflict re-reads and retries
  • • MarkRunTerminal sets status, cause, ended_at and releases the claim
  • • A failed publish does not un-cancel (internal/engine/mutator.go)

Why push needs no stream

  • • isRunCancelled calls store.GetRun before each step (executor.go)
  • • A cancelled run stops at the next boundary, not mid-step
  • • cancel_on cleanup and an audit event also run here