[jmeiss]

When a connect using sslnegotiation=postgres (the default with an ssl context) is cancelled while loop.create_connection() waits for its transport, the transport is closed and TLSUpgradeProto.connection_lost() then sets on_data with ConnectionError('unexpected connection_lost() call'). Nobody awaits that future, so asyncio logs:

Future exception was never retrieved
future: <Future finished exception=ConnectionError('unexpected connection_lost() call')>

The cancellation can come from the connect's own timeout or from a caller's asyncio.wait_for. We see it in production from a readiness probe whose connect to a slow server outlives its timeout. The same leak happens when the cancellation arrives after on_data already got its exception (the task is cancelled before it reads the result).

__connect_addr() already handles this for its connected future. This change does the same for the SSL upgrade:

• _create_ssl_connection() keeps a reference to the TLSUpgradeProto it creates, and discards on_data when create_connection() fails or is cancelled.
• It also discards on_data when awaiting it fails, so an exception set in the same loop iteration as the cancellation is retrieved.
• A small _discard_future() helper (cancel if pending, otherwise retrieve the exception) is shared with the existing connected handling.

The new test TestConnectionCleanup.test_cancelled_ssl_upgrade_leaves_no_orphan_future needs no cluster. It cancels a connect to a local server that never answers at each event-loop step, with direct_tls off and on, and asserts that the loop's exception handler was never called. Without the fix it fails with the message above; with it, it passes. tests/test__sourcecode.py (flake8, mypy) passes.

🤖 Generated with Claude Code