tranport.get_extra_info('peername') occasionally returns None

uvloop version: 0.17.0
Python version: 3.11.4
Platform: Linux

I believe the root cause of this issue is that:

• libuv doesn't retrieve peer address while calling accept()
• getpeername() fails if the client disconnected already (which is unlikely, but possible)

Here's strace log:

561904 setsockopt(19, SOL_TCP, TCP_NODELAY, [1], 4) = 0
561904 accept4(18, NULL, NULL, SOCK_CLOEXEC|SOCK_NONBLOCK) = -1 EAGAIN (Resource temporarily unavailable)
561904 getsockname(19, {sa_family=AF_INET, sin_port=htons(32111), sin_addr=inet_addr("127.0.0.1")}, [128 => 16]) = 0
561904 getpeername(19, {sa_family=AF_INET, sin_port=htons(39898), sin_addr=inet_addr("127.0.0.1")}, [128 => 16]) = 0
561904 getpid()                         = 561904

Please note, that standard asyncio loop uses accept4() call to get the peer address:

564955 accept4(13, {sa_family=AF_INET, sin_port=htons(35516), sin_addr=inet_addr("127.0.0.1")}, [16], SOCK_CLOEXEC) = 16
564955 getsockname(16, {sa_family=AF_INET, sin_port=htons(32111), sin_addr=inet_addr("127.0.0.1")}, [128 => 16]) = 0
564955 ioctl(16, FIONBIO, [1])          = 0

Said that, there's an issue raised in libuv repo which should be addressed first, I suppose: https://github.com/libuv/libuv/issues/3339

Start by reproducing the uvloop 0.17.0, Python 3.11.4 case on Linux and tracing the accept/getpeername behavior shown in the report. Then review the linked libuv issue #3339; done means the cause is confirmed and peername behavior is verified after an actionable fix or dependency resolution.