Same API called twice after timeout
Verdict
When the same API operation is executed twice after a timeout, this is usually not a client-side mistake, but a consequence of uncertain execution boundaries.
A timeout does not reliably indicate failure. If the server may continue processing after the client times out, repeating the request shifts risk from non-execution to duplicate execution.
At this boundary, retrying becomes a risk decision, not a correctness requirement.
Why This Happens
Across distributed systems, timeouts sever visibility—not execution.
Common structural causes include:
- In-flight execution that completes after the client timeout
- Asynchronous workers or queues that outlive request lifetimes
- Network delays that hide successful completion
- Lack of end-to-end execution guarantees exposed to the client
From the client’s perspective, the request “failed.” From the system’s perspective, it may have already succeeded.
Calling the API again creates a second valid instruction.
Where You Can Stop
Once a timeout is followed by duplicate effects, you can usually stop:
- Automatically retrying timed-out requests
- Treating timeouts as proof of non-execution
- Layering retries across multiple client components
- Assuming duplication reflects faulty client logic
Further progress depends on explicit execution guarantees, not additional retries.
What This Page Is Not
This page does not:
- Define safe retry patterns
- Provide deduplication techniques
- Resolve duplication after it occurs
Its role is to clarify when retrying after a timeout crosses from recovery into risk.
A timeout ends visibility, not responsibility.