Aglet

Investigate an API timeout retry loop

Investigation should follow one operation through the moment the response disappears and every later choice. Pair a pre-dispatch failure with a delayed completion, then compare retry and readback behavior. Keep transport, remote latency, client cancellation, and missing operation identity as competing explanations.

Build a useful investigation brief

  1. Build timeout fixtures

    Create a fast success, a connection failure before dispatch, a delayed response after dispatch, a client cancellation, and a permanent rejection. Label expected operation identity and safe recovery before execution. Include a write and a read where retry meaning differs.

  2. Trace dispatch and state

    Capture request start, bytes-sent or dispatch signal, timeout, response arrival, retry decision, operation key, and local state. Compare the first point where an attempt becomes unknown. Keep transport logs bounded and redact payloads or credentials.

  3. Challenge retry safety

    Vary timeout duration, remote delay, cancellation, response loss, and key reuse one at a time. Use readback to distinguish completed from absent work. If the remote result is unavailable, state that limitation and do not infer completion from a later timeout alone.

What to carry forward

The investigation is ready when fixtures show dispatch, timeout, identity, readback, retry, and local-state transitions for one operation. Deliver a finite retry or reconciliation change. Leave network and remote completion boundaries explicit where local evidence ends.

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