Aglet

Learn from API timeout retry loops

The durable lesson is a clear handoff from network uncertainty to operation reconciliation. Preserve the dispatch point, timeout class, identity, and readback evidence that resolved the case. State which failures can retry and which must remain pending when the remote result cannot be observed.

Keep the lesson for the next incident

  1. Document timeout classes

    Record pre-dispatch, post-dispatch, response-loss, cancellation, and remote-rejection behavior. Define operation identity, retry budget, readback owner, local pending state, and safe terminal outcomes for each operation class. Retain the final readback after a lost response.

  2. Keep recovery fixtures

    Retain fast, delayed, lost-response, restart, permanent-error, and unknown-write cases with synthetic resources. Store expected attempt counts and final states. Include the original loop trigger so transport or worker changes can be compared against it.

  3. Review loop signals

    Watch attempts per operation, unknown writes, late responses, readback failures, and timeout class by client revision. Assign an owner and threshold. Close the follow-up only when finite recovery and identity checks run in every relevant environment.

What to carry forward

Close learning with timeout classes, retry and reconciliation ownership, recovery fixtures, and loop signals. Keep remote timing limits explicit. The useful outcome is a deliberate choice between retry, readback, and review when a response disappears again. Keep the original operation identity through recovery.

Technical background: Stripe documentation.

Keep the decision with the work.

Use a Work Item in Aglet to record the problem, the evidence you have, and the next decision. Add an owner and priority, then keep updates in the discussion so the next person can follow the reasoning.

Create an account See the product workflow