A local teaching model / no account / no uploads

Async Failure Lab

The debit succeeds. The worker crashes before recording the result. Should the next attempt call the tool again?

Choose a failure, compare the two runtimes, and follow the event trace. The model separates delivery attempts from business effects. It reuses the simulation in Agent Loops: Distributed Transactions Without Atomic Commit.

Loading the interactive controls. The assumptions and local command below remain available without the interactive view.

What this model assumes

One virtual debit operation and a single injected fault; no real payment, broker, or network is used.
The durable case assumes a stable operation key and a downstream contract that can deduplicate or look up that same intent.
The downstream idempotency record is retained throughout the modeled retry window and is atomically tied to the effect.
Operation lookup eventually succeeds, storage is available, and authorization is checked before dispatch.
Outages of the lookup service, expired deduplication records, concurrency, and timing distributions are not modeled.

These are deterministic examples, not production measurements, a Kafka broker implementation, or a reliability guarantee.

Run the same model locally

From a checkout of this site with its existing dependencies installed:

pnpm run lab:async --fault crash-after-effect --mode durable

Expected result: two dispatch attempts, one modeled effect, and "Recovered by operation key". The JSON includes the same assumptions and events as the browser. It does not contact a real broker, payment provider, or model API.

Take the replay-readiness checklist to your own design

Stress the idempotency contract

The original failure model assumes a stable key and a retained record. This separate two-request experiment relaxes those assumptions. Its inputs stay in page memory, never in a share URL or analytics; the original model and CLI remain unchanged.

Choose identity and retention

Idempotency key scope

A delivery attempt is not the identity of a business intent.

Second request

Fictional requests only; no real operation or tenant data is needed.

Retained payload conflict policy

Does the receiver compare a canonical request fingerprint?

Idempotency retention (seconds)

Record and effect are atomically bound; only the record expires.

Second request after (seconds)

At the exact expiry boundary the record is already absent.

Same intent reused its retained result

Record at second request

Retained

Second disposition

reused

Applied, reused, or conflict

Total effects

Both requests express one intent

Fictional requests and their receiver keys
Attempt	Business identity	Amount (minor units)	Receiver key	Fingerprint tuple
1	tenant-a / order-42	1200	`["tenant-a","order-42"]`	`["tenant-a","order-42",1200]`
2	tenant-a / order-42	1200	`["tenant-a","order-42"]`	`["tenant-a","order-42",1200]`

Identity experiment boundaries

Two sequential requests use fictional tenants and operation IDs. This extension does not change the original Async Failure Lab or model concurrent claims.
The record and effect commit atomically. A duplicate lookup at or after the retention boundary no longer finds the record; there are no independent business uniqueness constraints.
Identity is the pair (tenant, business operation), not the delivery attempt. A canonical tuple stands in for a request fingerprint, not a production cryptographic hash or normalization scheme.
An enforced fingerprint rejects a reused key with different tenant, operation, or amount. Ignoring it can hide a conflicting request behind a previous result.
Retention expiry does not make repeating an effect correct. Real retention, authorization, replay windows, and reconciliation must be checked at the downstream boundary.