Recover without repeating costly actions
A timeout does not tell you what happened
A read request can time out before returning data. A write request can time out after the external service acted. These are different problems. Repeating an order blindly can create a duplicate even if the first response never arrived.
For a read, use a small retry limit and surface failure when it is exhausted. For a consequential write, reconcile status before retrying. An idempotency key can help a supporting service recognize repeated attempts at the same logical operation.
Check your understanding
A purchase request timed out after being sent. What is the safest next step?
Put boundaries around recovery
A useful retry policy names which failures qualify, the maximum attempts, and what happens next. Temporary network errors may qualify; invalid quantities do not. Infinite retries turn uncertainty into cost and poor experience.
The lab simulates a timeout after a submission was accepted. Retrying the same unchanged submission returns the stored simulation receipt rather than creating a second one. It models deduplication in memory; a real backend must persist it and follow the provider’s guarantees.
Check your understanding
Tell the user the state you actually know
“I could not confirm the result yet” is different from “The order failed.” Avoid announcing success or failure without evidence. Provide a recoverable status, retain the proposal, and identify the next check.
Try the timeout scenario and count the receipts. Your product goal is not merely fewer error banners; it is preserving the user’s intent without duplicate actions. Keep a trace of the attempt and reconciliation result.
Check your understanding
Write the user-facing message for an uncertain submission result.
Build checkpoint
Open the Workflow Lab and follow the practice above. Each lab explains its inputs, its actual logic, and its limits. Save your observations below; your check-ins and reflection remain in Product Academy.
For an AI-assisted code change, download the lab bundle from the lab page. Ask your coding assistant to explain the relevant function first, change one behavior, and add one test that could fail. Compare the result with your prediction.
Save your experiment and check-in
Record your prediction, what you tried, what happened, and the evidence for your conclusion. Name one thing you can now do independently and one uncertainty to revisit.
Key takeaways
- Treat uncertain writes differently from failed reads.
- Bound retries and reconcile ambiguous outcomes.
- Test duplicate prevention, not just successful responses.