How do we prevent duplicate actions when retrying a request?
3 min readFirst reconcile whether the original operation was accepted or completed. Use the exact operation’s documented retry and idempotency behavior rather than treating a lost response as permission to submit a new action.
A missing response is not proof of no action
A request can reach the server and be accepted even if the response never reaches the application. Repeating it as a new request may therefore create another action. Keep the original operation reference and any documented request identifier. First inspect the responsible service’s state to determine what happened. This is especially important for payments and other writes whose effects are not safely undone by simply refreshing the page.
Idempotency is a specific behavior
An idempotent operation handles an appropriate repeat without creating an additional effect under its defined rules. That behavior must be documented for the actual endpoint. It may depend on a particular key, time window, or request shape; do not invent a header or assume every write shares the same guarantee. Disabling a button after one click can improve the interface, but it does not solve duplicated network delivery or a retry from another process.
Test the uncertainty deliberately
In an agreed environment, examine a lost response, delayed status, and duplicate delivery. Confirm which record the application reads before deciding whether another request is safe. Keep event delivery separate from the business action it may trigger, and check the receiving system’s own rules before causing a side effect. Explain the outcome to users as pending confirmation when appropriate. A reliable retry strategy is based on the observed contract, not on an arbitrary delay followed by another write.
Illustrative example
A payment response is lost; the application checks authoritative status before deciding whether any retry is safe.
Conditions & limitations
There is no universal idempotency guarantee implied for every endpoint. Do not invent an idempotency header or assume repeated writes are harmless.
What to do next
Test lost responses and duplicate delivery against the deployed contract and retain the observed result.