Saga compensation needs its own failure path

A workflow can fail after another system has already accepted its work. Returning an error does not recall that external action. A saga therefore needs a second design: what compensation does, how it can fail, and who resolves the uncertainty left behind. Choosing a workflow engine does not settle those business decisions.

Cloudflare's June 25, 2026 account of saga rollbacks puts compensation beside the forward step and runs eligible handlers in reverse step-start order. Those are useful execution rules. They cannot establish that an external action has a meaningful inverse. That distinction belongs in the requirements before implementation begins.

Reversal creates another action

Compensation changes the world again. It cannot make the original action cease to have happened. When requirements describe something as reversible, ask which outcome must be restored and which consequences remain acceptable. Restoring a business balance can leave a history of both actions, a delay between them, and work for someone outside the workflow.

The important boundary is ownership. Inside one database that the application controls, a local transaction may keep a group of changes atomic. Across independently committed services, the coordinator cannot simply make those commits disappear. Google's February 4, 2022 saga tutorial provides background on composing local transactions with compensation. It predates the Cloudflare announcement by years; it is not another June release.

Use that distinction to challenge the architecture. If the supposed distributed transaction only touches one owned database, a local transaction is usually the simpler starting point. A saga introduces intermediate states and recovery obligations. It should earn that complexity through a real boundary between systems, rather than through a preference for a fashionable pattern.

Ordering does not define business correctness

Step-local handlers keep the forward action and its recovery logic close enough to review together. Cloudflare describes reverse start order rather than reverse completion order, which matters when steps overlap. Completion timing is not a reliable description of how work was initiated.

An ordering rule still answers only which handler runs first. It does not prove that one business operation can safely follow another. Write down dependencies between compensations separately. If the chosen execution order cannot respect them, change the workflow design or the recovery policy. Do not silently assume that reversing a list reconstructs the original business state.

This is also why compensation differs from saving intermediate job state. A coordinator may accurately remember every value it persisted while another service has accepted an action whose result never reached it. Better serialization alone cannot reconcile that difference. The recovery design has to reason about the external service's state and the meaning of the original request.

Missing output is a real state

Cloudflare explicitly includes the possibility that a failing step registered compensation but never persisted output. Its handler must tolerate output === undefined. A step that failed to return a result may still have interacted with an external system. Treating missing output as proof that nothing happened leaves precisely the uncertain case unhandled.

For each external action, define how to distinguish confirmed completion, confirmed noncompletion, and an unknown outcome. The last category needs an identity that survives the missing return value. Decide what evidence the external system can provide and what the application should do while that evidence is unavailable. Guessing completion and repeating the forward action can create another effect.

Idempotency belongs on the compensating action too. To be idempotent, repeated compensation must converge on the intended business adjustment rather than repeat it without limit. The forward operation's idempotency policy does not automatically cover a different request made in the opposite direction. Review the identity, scope and retention of each operation independently.

Recovery must survive a failed compensation

An automatic recovery path is only as useful as its stopping rules. Decide which failures merit another attempt and which require a person. A permanent business rejection and a temporary transport failure should not become the same undifferentiated retry loop. Waiting longer cannot create a business permission that the compensating operation lacks.

Give the person responsible enough context to act: the original intent, the known external result, the compensation attempts and the remaining uncertainty. Preserve the original failure separately from recovery progress. Otherwise an operator can see that cleanup failed without being able to discover what the application was trying to clean up.

Define success in business terms as well as technical terms. A handler returning successfully is useful evidence about that handler. The wider question is whether the required adjustment has been confirmed, whether dependent work can continue, and whether any residual obligation remains. A workflow marked failed may still require business attention after all automatic retries have stopped.

Buy the boundary you can operate

The strongest argument for sagas is practical: independent systems already commit independently, so explicit recovery can be clearer than scattered error handling. That argument is convincing when the business accepts temporary inconsistency and has a workable compensation policy. It weakens when the required promise is indivisible completion across actions that cannot be compensated.

Before choosing the engine, review one failed forward action and one failed compensating action on paper. Name the evidence needed to resume, the person who can intervene, and the condition for closure. For custom software development, those decisions belong in the agreed scope. The useful deliverable is a failure path the business can operate when automatic recovery reaches its limit.