Retry explorer: what happens when the reply is lost
A phone sends one message. The reply can get lost, and then the phone does not know if the message arrived. Change one setting and see how many copies the server saves.
The idea
A phone sends one chat message. The server saves it and sends back a short reply that says it worked. If that reply is lost, the phone sees an error. The phone cannot tell if the server saved the message or not.
So the phone tries again. Without protection, the server may save the message twice. An idempotency key stops this. It is an ID that the phone adds to the message. The server sees the same key again and does not save a second copy.
These are the rules from the chat app case. A network error, a 408, a 429 and a 5xx error are temporary, so the phone tries again. Any other 4xx error is permanent, so the phone stops. The phone makes at most 8 attempts. The wait starts at 10 s and doubles.
Try it
Result
Timeline
- Press "Run the simulation" or pick a preset.
What this shows
Run the simulation to see what it shows.
Without JavaScript
The controls in Try it need JavaScript. If JavaScript is off, use this table. It shows what the four presets give. With JavaScript on, you can change every setting and run your own tests.
| Preset | Saved on the server | Time | Final status |
|---|---|---|---|
| The reply is lost (no key) The first send is saved, but its reply is lost. The phone waits 10 s and sends again. The second send works. | 2 saved, 1 duplicate | 10.6 s | Sent |
| The reply is lost (with key) The same story, but the phone sends an idempotency key. The server sees the key again and saves nothing new. | 1 saved, 0 duplicates | 10.6 s | Sent |
| The server is down for a while The server returns 500 five times. The phone waits 10, 20, 40, 80 and 160 s. The sixth send works. | 1 saved, 0 duplicates | 5 min 12 s | Sent |
| A bad request The server returns 400 on the first send. This error is permanent, so the phone does not retry. | 0 saved, 0 duplicates | 0.3 s | Failed |
How the model works
From the case:
- Temporary errors: a network error, 408, 429 and 5xx. Permanent errors: any other 4xx.
- At most 8 attempts. After that the phone marks the message failed. This is the ninth run, after the last wait.
- The wait starts at 10 s and doubles each time: 10, 20, 40 s and so on.
- A 429 reply may carry a Retry-After header (a hint about how long to wait). The worker does not read it. It uses its own wait. This tool does the same.
- With jitter, each wait changes at random. The case uses jitter when a live connection (a socket) reconnects.
- One reply takes about 0.3 s.
My own choices for this tool, not from the case:
- A timeout is 30 s. A timeout counts as a network error.
- A 429 asks for a wait of 20 s.
- A 5xx, a 429 and a 400 save nothing on the server.
- A jittered wait is 50% to 100% of the normal wait. A fixed seed makes the same run give the same result every time.