Skip to main content
Superseded by 0102: the workflow engine runs steps in-process with a Postgres journal; authoring is the declarative @Step graph of 0094.

​
Context

Multi-step business operations (create order, charge, reserve stock) must be able to undo earlier steps when a later one fails. Services own their data (0014) and call each other through events or clients, so database transactions cannot span them. A step-and-compensation model, as in Medusa, fits and is readable.

​
Decision

  1. A package @stackra/workflow provides createStep(name, invoke, compensate?) and createWorkflow(name, composer).
  2. A step has an optional compensation function. On failure, completed steps are compensated in reverse order.
  3. Steps and workflows are resolved through the container (0042); workflows live in a module’s application/ (0040).
  4. Step inputs and outputs are typed; a workflow’s input and output are its public contract.
  5. Steps are idempotent so a retry or a re-compensation is safe.
  6. Persistence of workflow state, retries and long-running execution are not decided here (TODO).

​
Consequences

  • Cross-service operations get one shape and one place to look for rollback logic.
  • Without persisted state, a crash mid-workflow loses compensation; point 6 must be settled before money flows through it.
  • Package category: TODO (see 0028).

​
Enforcement

Planned — conformance tests in the package for compensation order and idempotent retry; no check yet on authored workflows.

​
Supersedes and sources

Supersedes: none. Sources: owner decision in chat, 2026-10-19.