Aglet

Prioritize API timeout retries by duplicate risk

An unknown write can matter more than many failed reads, while a shared transport timeout can affect every caller. Prioritize by side-effect exposure, operation reach, attempt growth, and reconciliation cost. Preserve pending work rather than making a queue look clear through repeated mutations.

Decide where the work belongs

  1. Classify the unknowns

    List operation, resource, attempt count, timeout class, and current local state. Separate reads, idempotent retries, writes with a known result, and writes with no result. Attach the evidence that shows whether bytes could have reached the remote service.

  2. Compare containment

    Assess pausing mutations, safe readback, finite retry, queueing, or owner review. Record what each action leaves unresolved and which authority it needs. Do not raise timeout or retry limits until the operation identity and transport boundary are understood.

  3. Set retry priority

    Queue unknown writes and shared loops first, then blocked reads and isolated client timeouts. Set a maximum attempt, owner, review time, and reprioritization trigger. If readback is unavailable, make the evidence gap itself visible in the queue.

What to carry forward

Return a timeout queue with operation effect, attempt history, transport evidence, safe containment, reconciliation owner, and review trigger. Escalate unknown writes and shared retry waves. Keep ranking provisional when remote completion cannot be checked. Keep the unknown result visible.

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