Cloudflare has added saga rollback support to Cloudflare Workflows, its platform for building durable, multi-step applications with retries and state persistence. The update lets developers declare compensation logic directly inside a step, so that if a later step fails, earlier completed work can be automatically undone.
Workflows are commonly used for processes that span multiple external systems, such as transferring funds between two banks. In that example, a workflow might debit an account at Bank A, credit an account at Bank B, then send confirmation emails. If the credit step fails after the debit has already succeeded, the money cannot simply be “undone” at Bank A. Instead, a new operation must reverse the original one, a pattern known as the saga pattern.
Previously, developers had to write their own tracking logic to record what succeeded and manually trigger reversals in a catch block, ordering the rollbacks themselves and handling retries. With this release, rollback logic can be passed as an options argument directly to step.do(), alongside the step it corresponds to.
How it works
Key behaviors developers should understand include:
- Failed steps can still roll back. If a step registers a rollback handler and then fails, that handler may still run later if the workflow ultimately fails, since the step may have partially interacted with an external system before erroring. Rollback handlers receive the step’s output but must handle cases where it is undefined.
- Rollback only triggers on workflow failure. Registering a rollback handler does not mean every step error triggers it. If application code catches an error and the workflow continues normally, no rollback occurs. Rollback begins only when the workflow is about to fail terminally, at which point Workflows locates all eligible steps and runs their rollback handlers before recording the final failure.
- Rollback order is reverse step-start order. When a rollback runs, handlers execute in the reverse order the steps started, similar to unwinding a stack.
Cloudflare emphasizes that rollback functions must be idempotent, just like regular workflow steps. If a rollback refunds a charge, it should use the payment provider’s idempotency key. If it releases inventory, that release should be safe to call more than once, since retries can occur.
Why it matters
For developers building multi-step automation on Workflows, such as payment processing, order fulfillment, or any process touching multiple external APIs, this removes the need to hand-roll compensation tracking and manual undo ordering. Rollback logic now lives next to the step it protects, and Cloudflare’s durability guarantees extend to the rollback execution itself.