← Back to Labs
Retries and Idempotency Lab
See how the same write request behaves when the response is clean, lost after commit, or retried before the first attempt ever commits.
Failure scenarioChoose what the caller and the server experience
Business effect
one charge, replayed result
server replays the original 201 result
What the duplicate guard knows
key present: yes
store state: completed and still valid at +2h
retry branch: replay
store state: completed and still valid at +2h
retry branch: replay
Operational reading
first attempt committed: yes
caller saw final response: no
duplicate risk open: no
caller saw final response: no
duplicate risk open: no
Replay surfaceWhat a later caller would observe
HTTP/1.1 201 Created Idempotency-Replay: true Idempotency-Key: idem_ord_4819 { "paymentId": "pay_712", "status": "authorised" }
Step 1 / 6The client names one logical operation
The first request is just a write attempt until the client gives it a stable identity that can survive network retries.
Arrow keys to navigate · R to reset
Tap dots to jump to any step