What problem is this actually causing in real life?

the asyncio callback also raises AttributeError

What is "the asyncio callback" in this context?

The concrete effect I reproduced is an extra, uncaught event-loop exception during cleanup after a proxy rejects CONNECT with 407 (for example, incorrect proxy credentials). connect() still raises the correct InvalidProxyStatus; this fix doesn't make the rejected connection succeed. I don't have a production incident or evidence of data loss or a hang to claim.

By “the asyncio callback” I meant _SelectorSocketTransport._call_connection_lost(), which calls HTTPProxyConnection.connection_lost(). The traceback is:

_SelectorSocketTransport._call_connection_lost()
  -> HTTPProxyConnection.connection_lost()
  -> HTTPProxyConnection.run_parser()
  -> response.status_code
AttributeError: 'NoneType' object has no attribute 'status_code'

The CONNECT response parser already completed when it reported 407. Cleanup resumes that exhausted generator, whose next StopIteration has no response value.

I re-ran the loopback integration on Python 3.13.11: a real local CONNECT proxy, a WebSocket echo server, and the public connect(..., proxy=...) API. Correct credentials echo successfully; incorrect credentials raise InvalidProxyStatus on both versions. With the pre-fix client at acff86b, the loop's exception handler additionally receives the AttributeError above. With this PR's head, it doesn't. So the demonstrated user-facing problem is a spurious asyncio error log / exception-handler invocation on an otherwise correctly handled proxy rejection, not a failed error return from connect().