[itzzdev09]

Fixes #1175.

The bug

In TunnelHTTPConnection.handle_request() (_sync/_async http_proxy.py), a proxy CONNECT that succeeds leaves the underlying stream registered on self._connection. If the subsequent stream.start_tls() call then raises (e.g. a certificate/handshake failure), the exception was left to propagate without closing self._connection first — unlike the CONNECT-status-check branch a few lines above it, which already does exactly this on a non-2xx CONNECT response:

if connect_response.status < 200 or connect_response.status > 299:
    ...
    self._connection.close()
    raise ProxyError(msg)

self._connection already completed one successful request (the CONNECT) and self._connected stays False, so it keeps accurately reporting itself as ACTIVE, Request Count: 1 to the pool — nothing ever told it the tunnel died. The pool's own exception handling in handle_request() only removes the failed request from its queue, never the connection from self._connections, so it has no other way to notice. Each failed handshake permanently consumes a connection-pool slot; once failures reach max_connections, unrelated later requests raise PoolTimeout instead of the real ConnectError.

The fix

Wrap start_tls() the same way the status-check block already does:

with Trace("start_tls", logger, request, kwargs) as trace:
    try:
        stream = stream.start_tls(**kwargs)
    except BaseException:
        self._connection.close()  # aclose() in the async variant
        raise
    trace.return_value = stream

Applied to both _sync/http_proxy.py and _async/http_proxy.py (they're kept in sync via scripts/unasync.py, which I re-ran after editing the async source).

Testing

Added test_proxy_tunneling_with_tls_failure to both tests/httpcore2/_sync/test_http_proxy.py and tests/httpcore2/_async/test_http_proxy.py, following the existing MockStream/MockBackend pattern used by test_proxy_tunneling_with_403: a FailingTLSStream whose start_tls always raises ConnectError, run three times against a pool with max_connections=2, asserting not proxy.connections after every failure.

• Reverting only the fix reproduces the exact bug: the test fails with a stale ACTIVE TunnelHTTPConnection left in proxy.connections.
• With the fix applied, all three failures leave the pool empty, as expected.
• Also independently reproduced the original discussion's own repro script against this branch (before/after), matching its exact ConnectError → ConnectError → PoolTimeout sequence when reverted, and ConnectError ×3 with an empty pool after each, when fixed.
• ruff check / ruff format --check and mypy clean on all four touched files.
• Full tests/httpcore2 suite: 235 passed, only 3 pre-existing keepalive_expiry=0.0 timing flakes remain, which I confirmed also fail identically on unmodified main (unrelated to this change).
• scripts/unasync.py --check passes (sync/async stay in lockstep).

[codspeed]

Merging this PR will not alter performance

✅ 17 untouched benchmarks
⏩ 7 skipped benchmarks¹

---

_{Comparing itzzdev09:fix/tunnel-tls-failure-leaks-pooled-connection (acd25a5) with main (df9783d)}

Footnotes

1. 7 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[cubic-dev-ai]

All reported issues were addressed across 4 files

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[mbeijen]

I had the same fix open as #1010 (port of encode/httpcore#1049) and have closed it in favour of this one, since this one also handles cancellation and has the better regression test. One nit: the cleanup swallows BaseException from aclose(); except Exception would be enough to keep the TLS error from being masked, without hiding a KeyboardInterrupt. Otherwise LGTM.

[NorbertRop]

We hit this in production. A TLS reset during the handshake through our HTTP proxy (tinyproxy) left the tunnel in the pool as ACTIVE. Our client polls over a pool of one connection (python-telegram-bot’s long polling), so every later request failed with PoolTimeout until we restarted the process. Reproduced on httpcore2 2.13.1 and httpcore 1.0.9, and closing the proxy connection when start_tls fails, as this PR does, fixes it in our repro. Would be great to get this merged.