A failed response does not always mean the operation failed. A server may have completed a change before the connection was interrupted. Repeating it can then produce an unintended duplicate.
Read operations and state-changing operations need different treatment. Idempotency mechanisms can help some writes be repeated safely, but they must be supported by the actual service contract.
Bounded retries, backoff, and clear reporting make behavior easier to understand. When the outcome is uncertain, checking the resulting state can be more appropriate than blindly trying again.
- Distinguish a read from a state-changing action.
- Check the idempotency contract.
- Limit retries and verify uncertain outcomes.
An example to consider.
Consider requesting a public article again after a temporary interruption. That repeated read has different consequences from repeating an action that creates a record.
Put it in perspective.
Successful delivery and successful recovery are separate questions. Explore what must remain known when a request ends without a clear outcome.
Follow a related question
Name the activity the tool should improve.
New tools, familiar human questionsCheck the unit and time window.
From data to a useful questionKeep learning
Related background to continue exploring this subject.
AWS: timeouts, retries, and backoff Cloudflare: errors and exceptions
