Aglet

Triage API client connection pool exhaustion

A single API request can be healthy while concurrent callers exhaust the client pool. Freeze one bounded burst and record active connections, wait time, request duration, response size, and release path. Separate pool capacity from leaked responses, slow remote work, and retry pressure.

Establish what is happening

  1. Capture pool pressure

    Record pool size, active and waiting counts, endpoint, concurrency, request duration, timeout, client revision, and result class for a short window. Avoid raw payloads. Note whether failures occur during acquisition, transport, response read, or release.

  2. Compare one and many

    Run one request, a bounded concurrent group, and a slow-response case. Compare pool wait, connection reuse, completion, and release. A healthy single request narrows the issue; it does not prove that pooled connections are returned on failure.

  3. Bound capacity consumers

    Group symptoms by caller, endpoint, response size, timeout, client version, and concurrency. Separate pool exhaustion, remote slowness, leaked responses, and retry amplification. Preserve a cancellation or error case if it leaves capacity occupied.

What to carry forward

Triage ends with a measured pressure window, first capacity boundary, affected caller, and evidence gap. Stop before raising pool limits. Route transport, release, and concurrency questions separately. Keep capacity evidence available for review before changing limits.

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