GeezerVison

Note to myself: despite asyncio.start_server promises to be IPv4-first if family is undefined:

cpython/Lib/asyncio/base_events.py

Line 976 in 9523c0d

async def create_connection(

calls

cpython/Lib/asyncio/base_events.py

Lines 1034 to 1036 in 9523c0d

	infos = await self._ensure_resolved(
	(host, port), family=family,
	type=socket.SOCK_STREAM, proto=proto, flags=flags, loop=self)

that calls

cpython/Lib/asyncio/base_events.py

Line 1400 in 9523c0d

info = _ipaddr_info(host, port, family, type, proto, *address[2:])

that has the following lines:

cpython/Lib/asyncio/base_events.py

Lines 129 to 134 in 9523c0d

	if family == socket.AF_UNSPEC:
	afs = [socket.AF_INET]
	if _HAS_IPv6:
	afs.append(socket.AF_INET6)
	else:
	afs = [family]

, it creates an IPv6-only listening socket if possible. As a result, not only server.sockets[0].getsockname() returns an IPv6 address, the whole server refuses to accept IPv4 client connections. It took me two force-pushes to find out, so my apologises about flukes in the notifications.

Now, I'm sorting out what and why leaks all connected sockets (as Address sanitizer reports) failing all non-Windows runners:

/home/runner/work/cpython/cpython/Lib/unittest/async_case.py:134: ResourceWarning: unclosed <socket.socket fd=8, family=2, type=1, proto=6, laddr=('127.0.0.1', 32881), raddr=('127.0.0.1', 57190)>

/home/runner/work/cpython/cpython/Lib/unittest/async_case.py:134: ResourceWarning: unclosed <socket.socket fd=10, family=2, type=1, proto=6, laddr=('127.0.0.1', 36545), raddr=('127.0.0.1', 42800)>

/home/runner/work/cpython/cpython/Lib/unittest/async_case.py:134: ResourceWarning: unclosed <socket.socket fd=12, family=2, type=1, proto=6, laddr=('127.0.0.1', 35363), raddr=('127.0.0.1', 49040)>

/home/runner/work/cpython/cpython/Lib/unittest/async_case.py:134: ResourceWarning: unclosed <socket.socket fd=14, family=2, type=1, proto=6, laddr=('127.0.0.1', 39391), raddr=('127.0.0.1', 41928)>

/home/runner/work/cpython/cpython/Lib/unittest/async_case.py:134: ResourceWarning: unclosed <socket.socket fd=16, family=2, type=1, proto=6, laddr=('127.0.0.1', 42821), raddr=('127.0.0.1', 42452)>

The failure was a combination of client-side blocking wait of a server and a missing asyncio loop policy. Both problems are fixed.

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

And if you don't make the requested changes, you will be poked with soft cushions!

🤖 New build scheduled with the buildbot fleet by @asvetlov for commit 005ad9a 🤖

If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again.

LGTM. Let's wait for the buildbots fleet to finish to make sure that everything works smoothly.
Network code can lead to subtle test problems.

@asvetlov I fixed a forgotten self found by AMD64 FreeBSD.

The second runner, ARM64 macOS, failed on test_asyncio that is unrelated:

======================================================================
ERROR: test_get_cancelled (test.test_asyncio.test_queues.QueueGetTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/pull_request.pablogsal-macos-m1.macos-with-brew/build/Lib/asyncio/tasks.py", line 490, in wait_for
    return fut.result()
           ^^^^^^^^^^^^
  File "/Users/buildbot/buildarea/pull_request.pablogsal-macos-m1.macos-with-brew/build/Lib/asyncio/queues.py", line 158, in get
    await getter
    ^^^^^^^^^^^^
asyncio.exceptions.CancelledError

Network code can lead to subtle test problems.

Considering that the failed test_flags was marked as @requires_headers_trailers (not sys.platform.startswith("linux") and not sys.platform.startswith("solaris") and not sys.platform.startswith("sunos")), GitHub runners had no chance.

GitHub Ubuntu runner failed with Error: Cache service responded with 400 during upload chunk; I reopened the PR to retrigger the workflow.

I see. Test failures seem unrelated.
Let's run the buildbot fleet again.

🤖 New build scheduled with the buildbot fleet by @asvetlov for commit 03cae53 🤖

If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again.

Merged. Thanks!