Aglet

Verify API client connection pool limits

Pool verification should show predictable wait and release under success and failure. Run one request, bounded concurrency, slow response, timeout, cancellation, retry, and process restart cases. Inspect active connections and completed work instead of judging by average latency alone in every fixture.

Check whether the outcome improved

  1. Define capacity outcomes

    Write expected pool wait, active count, release count, timeout, retry, and local state for fast, slow, failed, cancelled, and concurrent requests. State the finite limit and which work may pause when capacity is full.

  2. Exercise lifecycle edges

    Run fixtures through acquisition, response read, error, cancellation, and retry. Confirm every path releases capacity exactly once and no retry starts before the operation permits it. Compare counters before and after each bounded group.

  3. Check isolation and restart

    Use two callers sharing the client and restart between requests. Verify one slow or failed operation cannot starve unrelated work indefinitely. Inspect logs for safe correlation and retain the client revision and load shape with results.

What to carry forward

Accept when bounded concurrency has known behavior, success and failure release capacity, retries are finite, and restart does not hide a leak. Keep remote saturation partial when uncontrolled. Record pool configuration, fixtures, counters, and caller coverage.

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