Aglet

Verify an API timeout retry budget

Timeout verification must distinguish a failed request from an operation whose response was lost. Test reads and writes with bounded attempts, preserved identity, and a readback path. Include a restart because in-memory attempt state can make a loop appear fixed during one process run.

Check whether the outcome improved

  1. Define timeout outcomes

    Write expected state for pre-dispatch failure, post-dispatch timeout, delayed success, permanent rejection, read timeout, and unknown write. State max attempts, readback requirement, local status, and evidence retained for each case.

  2. Run retries with identity

    Execute fixtures through the real client and compare attempt count, operation key, response correlation, and durable result. Confirm only safe requests retry automatically. Check that a retry does not create a new key or overwrite a pending state.

  3. Exercise restart and recovery

    Restart between timeout and retry, then perform the approved readback or review. Verify the loop remains bounded, final local state is explicit, and a late response is associated with the original operation. Retain logs without raw request bodies.

What to carry forward

Accept when each timeout class has a finite path, writes preserve identity and use readback when needed, and restarts cannot reset the budget silently. Keep remote timing partial when uncontrolled. Record fixtures, policy, attempts, and recovery evidence.

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