Aglet

Prioritize API connection pool exhaustion

Connection pressure should queue by work blocked and leak risk, not by average latency alone. A shared client used by writes deserves earlier review than an isolated report. Weigh concurrency, response duration, retry amplification, and whether increasing capacity would move the failure elsewhere.

Decide where the work belongs

  1. Map blocked callers

    For each symptom, record caller, operation, endpoint, pool wait, active connections, timeout, and local state. Separate a queue delay from a failed write or dropped response. Attach a bounded time window and client revision.

  2. Compare containment paths

    Assess reducing concurrency, pausing optional work, fixing response release, changing timeout, or reviewing remote latency. Record capacity and rollback implications. Do not simply enlarge the pool when release behavior or upstream limits are unknown.

  3. Set the capacity queue

    Queue shared pool exhaustion, occupied capacity after errors, and blocked writes first. Set owner, load fixture, review time, and evidence threshold. Keep isolated slow reads behind proof that the pool path is actually shared.

What to carry forward

Return a pool queue with caller impact, capacity evidence, safe containment, owner, and proof needed to change priority. Escalate leaked capacity and shared writes. Keep rank provisional when transport metrics are incomplete. Keep shared capacity risk visible to callers.

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