Durable transaction recovery after a lost response

Keep the operation recoverable under one owner

We kept the Rust Worker and added one SQLite-backed Durable Object. A stored, ordered command log is the authority for each session. Replaying that log reconstructs balances and original receipts together. An exact retry can recover its first receipt across requests and execution restarts, while the session remains valid and request capacity is available.

The decision fits a small public study: one shared coordinator, bounded sessions, and no external effects. It accepts a shared serialization point and dependence on Cloudflare’s runtime and storage. Independent capacity, longer retention, or a service that must deliver an external effect would reopen the design.

One public session, two committed transfers

The deployed API check completed on 2 October 2026. It exercised one bounded synthetic session at the public origin. A separate final read returned 650 operating units, 350 reserve units, two committed transfers, and 22 remaining authorized requests.

Six concurrent requests submitted the same new 100-unit transfer. One returned applied and five returned replayed. All six identified receipt 2. The additional effect was one 100-unit movement.

Break the execution, then inspect what survived

In the local compiled-WASM workerd suite, the test committed another transfer with its acknowledgement withheld, killed the runtime with SIGKILL, and restarted it against the same storage. Retries recovered both that latest receipt and an earlier original receipt. A separate test discarded a real HTTP response and then recovered the operation on retry.

Retention and capacity are part of the promise

A session expires 15 minutes after creation, with at most eight committed commands and 32 authorized requests. Reads and retries consume that allowance. Expiry ends replay authority: a new session cannot recover an expired session’s receipt. Request cleanup and an alarm release expired capacity, including while new v2 requests are paused.

All visitors share 32 live sessions, 60 admitted requests per minute, and eight creations per minute. Overload rejects work without evicting live receipts. One visitor can consume availability for others. These bounds are appropriate to a public demonstration; they do not provide a hard spending cap or protection against shared-capacity abuse.

A code restore cannot undo a stored transfer

The initial Durable Object class migration makes the pre-migration Worker an invalid rollback target. Recovery must preserve the class, binding, migration history, and records. The operator can set STUDY_ENABLED=false to pause v2 before object access, while v1 and existing expiry alarms continue, then deploy a compatible repair. Later code rollback requires a reader that understands the stored state.

The reference commits only its own synthetic ledger. It does not settle an external payment, promise exactly-once delivery to another service, or demonstrate recovery from a cloud-region outage. A production design with external effects must establish that provider’s identity, acknowledgement, and reconciliation contract. The browser cannot infer that an effect failed from a missing response.

Bring the uncertain operation to an assessment

A paid Critical Systems Assessment starts with the decision your team needs to make. Bring the write path, its callers, storage and migration history, and an example of an uncertain outcome. We identify who owns the command and state, reproduce the material failure, and compare a bounded repair with the alternatives your system can support.

The deliverable is a decision brief with evidence, operating limits, acceptance checks, and a staged execution plan your team can use. That work can lead into a Core Systems Engineering program when the decision calls for implementation. This reference supplies a concrete method; your system’s constraints determine the recommendation.