Retries, Idempotency, and Recovery
Retries, Idempotency, and Recovery
Fact-check status
Key jargon
| Term | Plain-language meaning |
|---|---|
| Retry | Repeating an operation after a transient failure. S1 |
| Backoff | Increasing delay between attempts, usually with randomness to avoid synchronized retries. S1 |
| Idempotency | The property that repeating the same logical operation does not duplicate its effect. S1 |
| Compensation | A deliberate action that reverses or offsets a completed step when full rollback is impossible. S1 |
Key concepts
- Read failures and side-effect failures require different retry policies. S1
- Persist intent, attempt, and outcome so recovery can distinguish not-started, in-flight, succeeded, and failed work. S1
Concept map
flowchart LR
A["Classify failure"] --> B["Check prior outcome and idempotency key"]
B --> C["Retry or compensate"]
C --> D["Persist final state"]Diagram semantics verified against S1 and S2 on 2026-09-02.
Model and tool calls fail through timeout, rate limit, provider error, invalid output, network ambiguity, or downstream partial completion. Retrying is safe only when you know whether the first attempt had an effect. S1
Effect states
proposed → authorized → submitted → succeeded
├── failed-no-effect
└── outcome-unknown → reconcile
Do not convert outcome-unknown into a fresh action. Preserve the original approval and idempotency key, query the provider, or require certified no-effect before creating successor authority. S1
Exercise
Model a payment in which the network drops after submission. Write recovery behavior for provider success, provider failure, and provider unavailable. No real transaction is needed.