Non-idempotent actions must not auto-retry
Aliases: idempotency · duplicate submit · non-idempotent retry
What it is
If sending a request one more time produces one more side effect—a charge, a message, an order, a counter bump—it is not idempotent. Non-idempotent work must not auto-retry: a timeout is not a failure, and sending again may turn one into two. Recovery should query state first, then decide whether to fill in, abandon, or let the person choose. This entry is about whether another automatic attempt is allowed. It is not about how many retries cap out.
Why it happens
A timeout cuts observation, not execution on the other end. The client thinks it did not succeed; the other end may already have finished. Auto-retry fires a second shot at the observation layer, and the execution layer may run again. An idempotency key, a dedup window, query-then-decide—these turn “try again” from re-execution into re-alignment. Without them, auto-retry bets the user’s money and the recipient’s inbox that the network is symmetric. A person may choose to click again after being told; that is an explicit second side effect. A machine cannot consent for them.
Studying it
On a task such as “debit one point,” inject “actually succeeded, client timed out,” and compare auto-retry with query-first.
Independent variables: whether the act carries an idempotency key, whether timeout auto-sends or queries, the default when the query itself fails. Dependent variables: duplicate side effects, rate of users believing failure when success already happened, whether a second attempt is blocked.
Do not use real money in the lab. Use countable side effects (mail to a lab inbox, points) and reconcile against the other end’s log.
Where it stops holding
Truly idempotent reads, and overlay saves (later write replaces earlier with no extra side effect), may auto-retry. An interface that looks like save but “each save appends a history row” is not idempotent. In a partial batch, items that already succeeded must not be auto-sent again with the failures. When the query itself fails, the default is “state unknown,” not re-execute.
Applying it
- Classify pay, send, and create requests: without an idempotency guarantee, a client timeout goes to query or “view result,” never to an automatic POST again.
- Where a key can be added, the client generates it on the person’s click, retries carry the same key, and the other end deduplicates.
- Copy for unknown state says “this may already have completed; check first”; the action is inspect, not do it again.
- Verify by letting the other end succeed and deliberately dropping the response, then watching whether the client produces a second side effect. If it does, the path is auto-retrying a non-idempotent act.