Recovery and retries
A retry must preserve the original operation identity and exact serialized event batch. The atomic store returns its prior receipt only after matching request identity, participant bytes, route fence, current ownership, and deletion fences. Changing any of those inputs is a conflict, not a new attempt at the same operation.
On this page
Recovery surfaces
| Pending work | Recovery contract |
|---|---|
| Selected command | Operation recovery checks current route admission and persisted completion evidence before resuming. |
| Event-only subscriber | Delivery state and claim leases identify work that can be retried after a worker exits. |
| External effect | IExternalEffectIntentStore.ListPendingAsync and ExternalEffectDispatcher.RecoverPendingAsync resume work with the original idempotency key. |
| Projection | Provider queue or marker state retains a handoff until the consumer applies and acknowledges it. |
Provider implementations add their own journals, route pins, and retention rules. SQL Server keeps transaction evidence in its database. KurrentDB-based routes may coordinate KurrentDB and SQL state through a broker journal; this is not a distributed transaction across both systems.
Incident handling
First establish the committed receipt or current stream head. Then inspect pending delivery, effect, and projection records. Preserve operation IDs, request identities, route epochs, and provider receipts while investigating. Do not delete evidence merely to unblock a retry. See troubleshooting and deployment checklist.
Example: Resume pending effects
A recovery worker lists pending durable intents and dispatches them through providers keyed by provider ID. Each provider must honor the original idempotency key.
public static Task<IReadOnlyList<ExternalEffectTerminalReceipt>> RecoverEffects(
IExternalEffectIntentStore intents,
IReadOnlyDictionary<string, IIdempotentExternalEffectProvider> providers) =>
ExternalEffectDispatcher.RecoverPendingAsync(intents, providers, 100);
Repair application read models
Projection catch-up and rebuilds separates delivery recovery, versioned rebuilds, and bounded data repair. Idempotency and ordering explains which source evidence each consumer retains.