Aglet

Triage an API timeout retry loop

A timeout hides whether a remote operation completed. Start with one timed-out request and record attempt number, operation identity, timeout class, and later readback. Keep a connection failure, lost response, client cancellation, and remote rejection separate until the durable result is known.

Establish what is happening

  1. Freeze the timed-out operation

    Record method, endpoint, environment, operation label, dispatch time, timeout duration, and attempt number. Redact payloads and credentials. Note whether the connection failed before dispatch, after bytes were sent, or after a response may have begun.

  2. Check for durable completion

    Use the approved readback or review path to compare remote resource identity, local state, and operation correlation. Do not send another mutation merely to learn whether the first completed. Preserve a pending or unknown state when readback cannot establish the result.

  3. Bound the loop

    Count attempts by operation, caller, timeout class, client revision, and final state. Separate a shared transport problem from a retry policy defect. Record whether each retry reused a safe identity, then stop the path that can repeat work without a result.

What to carry forward

Triage ends with a timed-out operation, dispatch boundary, readback result or gap, attempt history, and safe next action. Stop the loop while identity is unknown. Route transport, retry, and reconciliation questions separately. Preserve the operation for reconciliation.

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