Principle
Treat a timeout as an unknown outcome
No response is not the same thing as no effect.
When it fits
- A mutating remote request times out after it was sent.
When to avoid it
- Some services cannot reveal a definitive state immediately; preserve the uncertainty instead of inventing certainty.
Why it matters
After a timeout, keep both possibilities alive: the server may have applied the change and lost the response, or it may not have applied it. Use the service's request identity, status endpoint, reconciliation data or another authoritative check before deciding to issue a new logical mutation. This avoids duplicate actions and false recovery.
An example
A payment call times out; query or safely retry the same idempotent operation instead of creating a second payment.
Check your result
The recovery procedure does not equate communication failure with application failure.
Keep this limit in mind
- Some services cannot reveal a definitive state immediately; preserve the uncertainty instead of inventing certainty.
Evidence and sources
Amazon's idempotency guidance treats a timed-out mutating request as potentially having completed, which is why a retry needs stable request identity rather than a new logical operation.
The exact state must be checked using the specific service's contract; timeout does not mean either success or failure by itself.
Making retries safe with idempotent APIs · Retry scenarios where the response is lost