> ## Documentation Index
> Fetch the complete documentation index at: https://docs.agentium.in/llms.txt
> Use this file to discover all available pages before exploring further.

# Choose a recovery contract

> Distinguish conversation storage, snapshots, job delivery, and durable task recovery.

Start by naming the failure you need to survive. Different mechanisms preserve different things.

| Mechanism | Preserves or provides | Application responsibility |
| - | - | - |
| [Session storage](/storage/overview) | Conversation history | Identity, retention, backup, and concurrency |
| [Checkpoint](/features/checkpointing) | Captured conversation/state data | Selecting/restoring a snapshot; external effects are unchanged |
| [SSE replay](/transport/resumable-sse) | A bounded process-local stream replay window | Reconnection policy; execution does not become durable |
| [Queue](/queue/overview) | Background job delivery and configured retries | Redelivery/idempotency and worker shutdown |
| [Durable task](/durable/overview) | Persisted task/action/approval state with ownership fencing | Replay-aware driver, durable store, connector reconciliation, recovery sweeps |

## Consider a refund timeout

The tool sends a refund request. The payment service accepts it. Your connection closes before the receipt arrives. The local exception cannot tell you whether the refund happened.

A second request may duplicate the effect. Instead, use a stable business idempotency key and query the provider for authoritative evidence. Retain that receipt with the application operation. A durable action ledger can coordinate this decision only when the connector supplies a valid reconciliation contract.

## Choose what to persist

* **Input references:** immutable inputs or retained references, with ownership and integrity checks.
* **Action identity:** deterministic IDs and canonical arguments; the same ID must not mean a different action on replay.
* **Approval:** the exact prepared action, reviewer identity, and decision.
* **Outcome evidence:** a provider receipt or other authoritative result, not only a local log line.
* **Policy and budgets:** what was admitted and what must be rechecked before resumed work.

An in-memory durable store is useful for local tests but advertises that it is not durable. See the [store and supervisor guide](/durable/overview) for persisted execution.

## Exercise the failure, not only the happy path

Test a crash before dispatch, a crash after dispatch but before acknowledgment, duplicate delivery, lease loss, approval timeout, and cancellation with an in-flight action. Document whether each case resumes, waits for reconciliation, or requires an operator.

Cancellation is a request to stop work. It cannot retract an effect already accepted by another system. Queue migration also needs an explicit procedure; follow the [BullMQ migration guide](/queue/migration) before changing persisted scheduler formats.

## Rehearse an unknown outcome

Use a controllable local connector before testing a real payment or notification. The following is a failure exercise, not a promise that a standard harness driver can replay effects.

| Point in the timeline | Evidence to retain | Recovery decision |
| - | - | - |
| Prepare `refund:order-42` | Persisted task, action arguments and stable operation ID | Nothing dispatched yet; an admitted retry may prepare the same action |
| Remote service accepts the action | Provider-side idempotency record or receipt | The external effect exists even if the local response is lost |
| Worker stops before recording completion | Local action has no confirmed outcome | Do not interpret missing acknowledgment as failure to execute |
| New worker acquires valid ownership | Persisted action plus provider lookup for the same ID | Record the existing receipt, or wait for authoritative evidence |
| Provider cannot determine the outcome | Explicit unresolved state | Require reconciliation or an operator; avoid a blind duplicate dispatch |

Run the exercise once with the failure before dispatch and once after acceptance. Verify that the provider fixture records one effect for the operation ID. Then test lease loss and duplicate delivery. [Durable driver contracts](/durable/overview) describe the store, driver, and connector responsibilities; [queue durable delivery](/queue/durable) adds wakeups around them.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.