The Fix
Upgrade to version 0.15.3 or later.
Based on closed encode/httpx issue #1315 · PR/commit linked
Production note: Most teams hit this during upgrades or environment changes. Roll out with a canary and smoke critical endpoints (health, OpenAPI/docs) before 100%.
@@ -1505,7 +1505,7 @@ async def _send_single_request(
async def on_close(response: Response) -> None:
response.elapsed = datetime.timedelta(seconds=await timer.async_elapsed())
- if hasattr(stream, "close"):
+ if hasattr(stream, "aclose"):
await stream.aclose()
$ python3.8 -m asyncio
>> import asyncio
>> import httpx
>> c = httpx.AsyncClient()
>> await c.get('http://httpbin.org/')
<Response [200 OK]>
>> c._transport._connections
{(b'http', b'httpbin.org', 80): {<AsyncHTTPConnection http_version=HTTP/1.1 state=2>}}
>> await c.get('http://httpbin.org/')
<Response [200 OK]>
>> c._transport._connections
{(b'http', b'httpbin.org', 80): {<AsyncHTTPConnection http_version=HTTP/1.1 state=2>, <AsyncHTTPConnection http_version=HTTP/1.1 state=2>}}
Re-run the minimal reproduction on your broken version, then apply the fix and re-run.
Option A — Upgrade to fixed release\nUpgrade to version 0.15.3 or later.\nWhen NOT to use: Do not apply this fix if using a version of httpx that does not support async streams.\n\n
Why This Fix Works in Production
- Trigger: Async client does not close underlying stream thus leaving connection active which leads to hitting pool limit
- Mechanism: AsyncClient fails to close httpcore's stream after requests, causing connection pool limits to be reached
- Why the fix works: Fixes the issue where the AsyncClient does not properly close the underlying stream, leading to connection pool limits being reached. (first fixed release: 0.15.3).
- If left unfixed, the same config can fail only in production (env differences), causing startup failures or partial feature outages.
Why This Breaks in Prod
- Shows up under Python 3.8 in real deployments (not just unit tests).
- AsyncClient fails to close httpcore's stream after requests, causing connection pool limits to be reached
- Production symptom (often without a traceback): Async client does not close underlying stream thus leaving connection active which leads to hitting pool limit
Proof / Evidence
- GitHub issue: #1315
- Fix PR: https://github.com/encode/httpx/pull/1316
- First fixed release: 0.15.3
- Reproduced locally: No (not executed)
- Last verified: 2026-02-09
- Confidence: 0.85
- Did this fix it?: Yes (upstream fix exists)
- Own content ratio: 0.61
Discussion
High-signal excerpts from the issue thread (symptoms, repros, edge-cases).
“### Checklist <!-- Please make sure you check all these items before submitting your bug report. --> - [x] The bug is reproducible against the latest release and/or master. - [x] There are no similar issues or pull requests to fix it yet. #”
Failure Signature (Search String)
- Async client does not close underlying stream thus leaving connection active which leads to hitting pool limit
- ``AsyncClient`` doesn't close ``httpcore``'s stream after performing request, the bug shows itself in locking on connection pool's semaphore.
Copy-friendly signature
Failure Signature
-----------------
Async client does not close underlying stream thus leaving connection active which leads to hitting pool limit
``AsyncClient`` doesn't close ``httpcore``'s stream after performing request, the bug shows itself in locking on connection pool's semaphore.
Error Message
Signature-only (no traceback captured)
Error Message
-------------
Async client does not close underlying stream thus leaving connection active which leads to hitting pool limit
``AsyncClient`` doesn't close ``httpcore``'s stream after performing request, the bug shows itself in locking on connection pool's semaphore.
Minimal Reproduction
$ python3.8 -m asyncio
>> import asyncio
>> import httpx
>> c = httpx.AsyncClient()
>> await c.get('http://httpbin.org/')
<Response [200 OK]>
>> c._transport._connections
{(b'http', b'httpbin.org', 80): {<AsyncHTTPConnection http_version=HTTP/1.1 state=2>}}
>> await c.get('http://httpbin.org/')
<Response [200 OK]>
>> c._transport._connections
{(b'http', b'httpbin.org', 80): {<AsyncHTTPConnection http_version=HTTP/1.1 state=2>, <AsyncHTTPConnection http_version=HTTP/1.1 state=2>}}
Environment
- Python: 3.8
What Broke
Connection pool limits are reached, leading to request failures in long-running processes.
Why It Broke
AsyncClient fails to close httpcore's stream after requests, causing connection pool limits to be reached
Fix Options (Details)
Option A — Upgrade to fixed release Safe default (recommended)
Upgrade to version 0.15.3 or later.
Use when you can deploy the upstream fix. It is usually lower-risk than long-lived workarounds.
Fix reference: https://github.com/encode/httpx/pull/1316
First fixed release: 0.15.3
Last verified: 2026-02-09. Validate in your environment.
When NOT to Use This Fix
- Do not apply this fix if using a version of httpx that does not support async streams.
Verify Fix
Re-run the minimal reproduction on your broken version, then apply the fix and re-run.
Did This Fix Work in Your Case?
Quick signal helps us prioritize which fixes to verify and improve.
Prevention
- Add a CI check that diffs key outputs after upgrades (OpenAPI schema snapshots, JSON payload shapes, CLI output).
- Upgrade behind a canary and run integration tests against the canary before 100% rollout.
- Add a TLS smoke test that performs a real handshake in CI (include CA bundle validation and hostname checks).
- Alert on handshake failures by error string and endpoint to catch cert/CA changes quickly.
Version Compatibility Table
| Version | Status |
|---|---|
| 0.15.3 | Fixed |
Related Issues
No related fixes found.
Sources
We don’t republish the full GitHub discussion text. Use the links above for context.