Pattern
Treat a timeout as an unknown outcome before repeating the action
No reply is not the same as no action.
When it fits
- A send, create or update request times out after leaving your application.
When to avoid it
- Reconciliation against stale or incomplete data can also mislead. Do not invent an automatic retry rule for an undocumented interface.
What to look for
No reply is not the same as no action.
Why it matters
The receiver may have completed the operation while its response was lost. Preserve an unknown or pending state and reconcile using the operation's identity before creating a fresh request. Where a documented idempotent retry is available, follow that contract.
An example
An import request times out. Its run identifier reveals that the job is already processing, so a second import is not started.
Check your result
The status distinguishes confirmed failure from an unconfirmed outcome.
Keep this limit in mind
- Reconciliation against stale or incomplete data can also mislead. Do not invent an automatic retry rule for an undocumented interface.
Connected ideas
Useful withReuse the operation identity when retrying the same intent
Evidence and sources
Supports
A request that receives no response may already have created its intended resource; blindly retrying can create additional effects.
Reconciliation requires an authoritative receiver view and enough identity information to distinguish this operation from another.
Making retries safe with idempotent APIs · Retrying and side effects