@Marvin i need prefect 3 examples for the backward healing failires Backward Recovery Failure Modes Backward recovery — executing compensating transactions in response to a permanent failure — is the mechanism that restores a Saga to a consistent business-defined state. It fails quietly: the workflow appears to handle the error while leaving the system in a worse state than if it had never run. The failure modes below are distinct from forward recovery failures; they emerge from the compensation logic itself, not from retries. 1. Missing Compensation A step executes successfully and mutates external state, but no compensating transaction is defined. If a later step fails permanently, that mutation is stranded — the system has no path back to consistency. Signal: post-failure audits revealing orphaned records, reserved-but-never-released resources, or charges with no corresponding order. Fix: every state-mutating step must have a paired compensation defined before the step executes, not as an afterthought. No compensation, no mutation. 2. Non-Atomic Compensation The compensating transaction itself fails partway through, leaving the system in a partially compensated state — worse than either the committed state or the clean pre-transaction state. Signal: compensation acknowledged as started but external state still partially mutated; inconsistency between internal workflow state and downstream system records. Fix: compensations must be idempotent and retriable. A compensation that cannot be safely retried is not a compensation — it is a new failure surface. Apply the same idempotency discipline to compensations as to forward steps. 3. Wrong Compensation Order Compensations executed out of sequence produce referential integrity violations or business logic errors. Releasing an inventory reservation before voiding the payment that depended on it may trigger downstream re-allocation before the payment void completes. Signal: compensation completes without error but downstream systems are in a logically inconsistent state; errors appearing in systems that weren't part of the failed step. Fix: compensation order must be explicitly defined and enforced by the orchestrator, not assumed. Default to strict reverse-sequential unless the domain explicitly permits non-linear compensation. 4. Compensation of Already-Compensated State (Double Compensation) A compensation executes twice — due to an orchestrator restart, a duplicate trigger, or a race between concurrent failure handlers — producing a state that is doubly-reversed: a payment voided twice, inventory released twice. Signal: resource balances going negative; duplicate refund records; idempotency violations detected in downstream systems. Fix: compensations must be idempotent by key. The orchestrator must track compensation state durably so a restart replays the compensation status, not the compensation action. 5. Stale State Compensation The compensation operates on state that has changed since the original step committed. A payment authorization that expired before the compensation fires cannot be voided — the compensation succeeds from the orchestrator's perspective but has no effect on external state. Signal: compensation returns success but external state is unchanged; downstream records showing the original mutation still active. Fix: compensations must validate that the state they are targeting still matches the state they committed. If external state has drifted, escalate to manual review rather than silently succeeding. 6. Cascading Compensation Failure A compensation failure in step N blocks compensations for steps N-1, N-2 … leaving a growing set of committed mutations uncompensated. The longer the chain, the larger the inconsistency surface. Signal: a single compensation error causing multiple downstream systems to remain in committed state; compensation progress halting rather than continuing past the failed step. Fix: compensation failures must not silently abort the entire compensation chain. Route failed compensations to a DLQ immediately; continue compensating remaining steps where safe to do so; never let one stuck compensation hold the entire rollback hostage. 7. Compensation Latency Violation Compensations that take too long allow downstream systems to act on state that is about to be reversed. An order confirmation email sent before inventory reservation compensation completes leaves the customer with a confirmed order that will be cancelled. Signal: customer-facing or downstream-system actions observed after a compensation has been triggered but before it completes; race conditions between compensation and downstream consumers. Fix: define a maximum acceptable compensation window per step. Steps with tight windows must either complete compensation before downstream propagation or gate downstream consumers on compensation status explicitly. 8. Silent Compensation Success on Permanent External Failure The compensation call returns a success code, but the downstream system has already processed the original mutation irreversibly — a payment settled, a shipment dispatched. The orchestrator records the Saga as cleanly compensated while the real-world state is permanently committed. Signal: orchestrator reporting clean compensation while external audit logs show the original action as permanently settled; customer disputes or financial reconciliation failures. Fix: compensations against externally irreversible operations must be treated as escalations, not transactions. Route to manual intervention immediately; do not record as compensated until human confirmation is received.

Your message was too long, here's your message at the allowed limit: i need prefect 3 examples for the backward healing failires Backward Recovery Failure Modes Backward recovery — executing compensating transactions in response to a permanent failure — is the mechanism that restores a Saga to a consistent business-defined state It fails quietly the workflow appears to handle the error while leaving the system in a worse state than if it had never run The failure modes below are distinct from forward recovery failures; they emerge from the compensation logic itself not from retries 1 Missing Compensation A step executes successfully and mutates external state but no compensating transaction is defined If a later step fails permanently that mutation is stranded — the system has no path back to consistency *Signal * post-failure audits revealing orphaned records reserved-but-never-released resources or charges with no corresponding order *Fix * every state-mutating step must have a paired compensation defined before the step executes not as an afterthought No compensation no mutation 2 Non-Atomic Compensation The compensating transaction itself fails partway through leaving the system in a partially compensated state — worse than either the committed state or the clean pre-transaction state *Signal * compensation acknowledged as started but external state still partially mutated; inconsistency between internal workflow state and downstream system records *Fix * compensations must be idempotent and retriable A compensation that cannot be safely retried is not a compensation — it is a new failure surface Apply the same idempotency discipline to compensations as to forward steps 3 Wrong Compensation Order Compensations executed out of sequence produce referential integrity violations or business logic errors Releasing an inventory reservation before voiding the payment that depended on it may trigger downstream re-allocation before the payment void completes *Signal * compensation completes without error but downstream systems are in a logically inconsistent state; errors appearing in systems that weren't part of the failed step *Fix * compensation order must be explicitly defined and enforced by the orchestrator not assumed Default to strict reverse-sequential unless the domain explicitly permits non-linear compensation 4 Compensation of Already-Compensated State (Double Compensation) A compensation executes twice — due to an orchestrator restart a duplicate trigger or a race between concurrent failure handlers — producing a state that is doubly-reversed a payment voided twice inventory released twice *Signal * resource balances going negative; duplicate refund records; idempotency violations detected in downstream systems *Fix * compensations must be idempotent by key The orchestrator must track compensation state durably so a restart replays the compensation status not the compensation action 5 Stale State Compensation The compensation operates on state that has changed since the original step committed A payment authorization that expired before the compensation fires cannot be voided — the compensation succeeds from the orchestrator's perspective but has no effect on external state *Signal * compensation returns success but external state is unchanged; downstream records showing the original mutation still active *Fix * compensations must validate that the state they are targeting still matches the state they committed If external state has