Aglet

Investigate API connection reuse and pool leaks

Investigation should show which request path holds or waits for a connection. Build fast, slow, failed, cancelled, and concurrent fixtures, then trace lifecycle counters. Keep pool sizing, remote latency, response leaks, and retry fan-out as separate hypotheses for one measured load.

Build a useful investigation brief

  1. Build lifecycle load cases

    Create one request, a bounded concurrent batch, a slow body, a failed response, a cancellation while waiting, and a retry after timeout. Record expected active and released counts before running. Use a test endpoint or fixture under controlled ownership.

  2. Trace acquire to release

    Capture pool wait, socket assignment, response read, timeout, error branch, release, and retry attempt. Compare counters after success and failure. Look for a path that returns an error before releasing or starts another attempt while capacity remains occupied.

  3. Vary pressure inputs

    Change only pool size, concurrency, response duration, payload size, timeout, or retry policy. Compare whether pressure follows capacity or lifecycle cleanup. If a remote delay and local leak both fit, record the missing transport observation.

What to carry forward

The investigation is ready when controlled load shows acquisition, use, release, and retry transitions for each relevant path. Recommend a lifecycle or capacity change with a bounded load check. Leave upstream latency limits explicit where not observed.

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