[PR #11074/e550c78a backport][3.12] Fix connector not waiting for connections to close #11077
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a backport of PR #11074 as merged into 3.13 (e550c78).
What do these changes do?
This PR fixes an issue where
BaseConnector.close()
would return immediately without waiting for connections to actually close. This is a partial backport of #3733 that includes only the bug fix without any breaking API changes.The fix ensures that
close()
properly waits for all connection closures to complete by:proto.closed
futures from connections being closedasyncio.gather()
to wait for all closures to completeAre there changes in behavior for the user?
No breaking changes. The
close()
method will now properly wait for connections to close as expected, which is the correct behavior. The method continues to return an awaitable that emits a deprecation warning if not awaited.Note: When using the connector as a non-async context manager (deprecated pattern), the issue of not waiting for connections to close still remains. This is because
__exit__
calls_close()
synchronously and cannot await the connection closures. Users should use the async context manager pattern (async with
) instead. We cannot remove the sync context manager in 3.x as that would be a breaking change.Related issue number
Partial backport of #3733
fixes #1925 fixes #3736
Checklist
CONTRIBUTORS.txt
CHANGES/
folde