Workflows — Rollback support (per-step saga-style)
Key Points
- Saga-style per-step rollbacks
- Handlers run in reverse order
- Rollback outcomes in status & analytics
Summary
Workflows now supports saga-style per-step rollbacks. You can attach a rollback handler and rollbackConfig to each step.do(...); if an instance fails, rollback handlers run in reverse step-start order. Rollbacks support retries and timeouts, their outcomes are exposed in instance status responses, and analytics emit rollback lifecycle events to help distinguish forward vs rollback failures.
Key Points
- Add compensating logic directly to a step with the
rollbackoption (keeps cleanup next to the step it undoes). - Rollbacks run in reverse step-start order and support
rollbackConfigincludingretries(limit, delay, backoff) andtimeout. - Rollback outcomes are visible in instance status and emitted as analytics events for clearer debugging of failures.
- Ideal for multi-step operations touching external systems: inventory, payments, tickets, or provisioning.
Quick example (JS/TS)
Use inline options on a step: step.do("provision resource", async () => { /* produce { resourceId } */ }, { rollback: async ({ output }) => { /* deleteResource(output.resourceId) */ }, rollbackConfig: { retries: { limit: 3, delay: "15 seconds", backoff: "linear" }, timeout: "2 minutes" } }).
Actions for engineers
- Add per-step
rollbackhandlers for operations that require compensation. - Configure
rollbackConfigto match expected retry behavior and timeouts for cleanup actions. - Monitor instance status and workflow analytics to detect and investigate rollback vs forward failures.
Refer to the Workflows rollback options in the docs for detailed configuration and examples.