A timeout leaves an unanswered question.
Consider a hypothetical export service. A user asks it to generate a report, but the request times out before the interface receives confirmation. The report may not have started. It may still be running. It may already exist while the confirmation was lost. Repeating the request treats those different situations as if they were the same.
This is why a retry deserves its own design discussion. A second request can help recover from a temporary interruption, but it can also repeat the original effect. The important question is not only whether the request failed from the caller’s perspective. It is what the receiving system may already have done.
Begin by identifying the operation’s consequence. Reading a status, creating an export, and sending a notification have different effects. They should not inherit the same retry behavior merely because they share a network client.
Give one intended operation an identity.
For an operation that supports it, a stable request identifier can let the receiver recognize another attempt at the same intention. The same identifier must refer to the same intended action. Reusing it for a changed request creates ambiguity rather than removing it.
A receiver also needs a rule for remembering the identifier, associating it with a result, and handling attempts that arrive while the original work is still running. The exact mechanism depends on the platform and the required guarantees. An identifier in a log message alone does not implement safe repetition.
This property is commonly discussed as idempotency: repeating a supported operation should not multiply its intended effect. It is a behavior to design and verify at the relevant boundary, rather than a label that can be attached to any endpoint.
Bound the retry policy.
A retry policy should say which conditions justify another attempt, how long to wait, and when to stop. Immediate repeated requests can worsen pressure on an unavailable dependency. Delays and limits help keep recovery activity proportionate to the situation.
Some errors need a correction rather than another attempt. An invalid field, a missing permission, or a withdrawn resource may continue failing until something changes. Distinguishing these conditions can avoid a queue of work that repeatedly asks the same impossible question.
Define what happens after the automatic policy ends. A visible task state, a responsible operator, and an investigation note are more useful than silently abandoning the task or retrying forever.
Make manual recovery equally explicit.
An operator’s replay button should explain what it repeats. In the export example, resending the notification is different from generating the report again. If the interface cannot distinguish the completed step, the operator may create duplicate work while trying to be helpful.
Before offering replay, decide how the system checks existing outcomes and records the new attempt. The person using the control should see the relevant task identity and the possible effect. Permissions and confirmation should match the action’s consequences.
Test the uncertain case deliberately in an appropriate test environment. Let the original action succeed while withholding the caller’s confirmation, then review the behavior of a repeated request. The result should support the documented contract.
Ask about the effect before the mechanism.
A useful review question is: “If this action completes and the response disappears, what will the next attempt do?” The answer exposes whether the task needs an identity, an outcome check, a narrower replay action, or a human decision.
No single retry rule fits every system. Document the contract and its limits so the next maintainer can understand what repetition means in this particular operation.