Aglet

Investigate API rate limit headers and retry waves

Investigation should connect the first rate response to the traffic that followed it. Build a small burst fixture, capture headers and attempts, and compare a single caller with concurrent callers. Keep quota, secondary protection, local fan-out, and slow transport as separate hypotheses.

Build a useful investigation brief

  1. Build controlled traffic

    Create one request, a bounded parallel burst, and a repeated optional-read fixture. Record expected attempt count and safe outcome before execution. Include a response with timing headers and one without, but do not hard-code an external reset value as fact.

  2. Trace the retry path

    Capture response status and headers, backoff calculation, scheduler decision, worker attempt, and queue state. Compare timestamps across callers to detect synchronization. Preserve work identity so a retry wave is not counted as new business work.

  3. Vary the pressure source

    Change only concurrency, endpoint, operation type, client policy, or downstream delay. Compare rate responses with transport failures and timeouts. If headers cannot distinguish a quota from a secondary guard, document the missing remote signal and keep the conclusion bounded.

What to carry forward

The investigation is ready when controlled traffic reproduces the response and shows whether local retries amplified it. Deliver the first observable boundary, finite containment, and evidence request for any remote limit question. Avoid claiming a quota increase would resolve a local fan-out defect.

Technical background: GitHub 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