The exception should probably be just ignored. Andrew, thoughts?

Here's an example error traceback:

      Traceback (most recent call last):
        File "c:\projects\asyncpg\asyncpg\connection.py", line 1227, in _cancel
          await w.wait_closed()
        File "C:\Python38\lib\asyncio\streams.py", line 376, in wait_closed
          await self._protocol._get_close_waiter(self)
        File "c:\projects\asyncpg\asyncpg\connection.py", line 1202, in _cancel
          await r.read()  # Wait until EOF
        File "C:\Python38\lib\asyncio\streams.py", line 694, in read
          block = await self.read(self._limit)
        File "C:\Python38\lib\asyncio\streams.py", line 701, in read
          await self._wait_for_data('read')
        File "C:\Python38\lib\asyncio\streams.py", line 534, in _wait_for_data
          await self._waiter
        File "C:\Python38\lib\asyncio\proactor_events.py", line 280, in _loop_reading
          data = fut.result()
        File "C:\Python38\lib\asyncio\windows_events.py", line 808, in _poll
          value = callback(transferred, key, ov)
        File "C:\Python38\lib\asyncio\windows_events.py", line 457, in finish_recv
          raise ConnectionResetError(*exc.args)
      ConnectionResetError: [WinError 64] The specified network name is no longer available

Note: this is going to miss Python 3.8.1 as I'm releasing 3.8.1rc1 right now. Please address this before 3.8.2 (due in February).

Sorry, I've missed this issue.
I'll address it in a while.

Why is this issue marked as a release blocker? Is it a Python 3.8 regression, or just a regular bug?

The exception should probably be just ignored.

It looks like the "ERROR_NETNAME_DELETED" (win32 error 64) exception is already ignored in multiprocessing's connection.wait():

I think that we should still retain the ConnectionResetError for "ERROR_OPERATION_ABORTED", but just specifically ignore "ERROR_NETNAME_DELETED". Ignoring "ERROR_OPERATION_ABORTED" doesn't seem correct here since it's relied on for cancelling file I/O (see https://docs.microsoft.com/en-us/windows/win32/fileio/canceling-pending-i-o-operations).

The patch should be straightforward. I'll test it locally and then open a PR, unless Andrew is currently working on it.

Downgrading priority on this, agreed with Victor.

Is this open for a PR?

Is this open for a PR?

I opened a PR for this issue a bit ago (applies Yury's suggestion of suppressing the exception), just waiting on review from Andrew when he finds the time to do so.

I have noticed the following on Linux too:

Traceback (most recent call last):
  File "/config/custom_components/kef_custom/aiokef.py", line 327, in _disconnect
    await self._writer.wait_closed()
  File "/usr/local/lib/python3.7/asyncio/streams.py", line 323, in wait_closed
    await self._protocol._closed
  File "/config/custom_components/kef_custom/aiokef.py", line 299, in _send_message
    await self._writer.drain()
  File "/usr/local/lib/python3.7/asyncio/streams.py", line 339, in drain
    raise exc
  File "/usr/local/lib/python3.7/asyncio/selector_events.py", line 814, in _read_ready__data_received
    data = self._sock.recv(self.max_size)
ConnectionResetError: [Errno 104] Connection reset by peer

after which every invocation of await asyncio.open_connection fails with ConnectionRefusedError until I restart the entire Python process.

IIUC, just ignoring the exception will not be enough.

This issue is about the ProactorEventLoop for Windows specifically, however, my process uses the default event loop on Linux.

Python 3.9.6 Linux same issue.

It looks like there's additional information here: #93821 - including a proposed patch.

While this is under investigation, are there any known workarounds for this issue at present?

A PR with the proposed fix is gh-18199 (found in gh-93821 -- thanks for the link, @iUnknwn). This changes the special handling of ERROR_NETNAME_DELETED in recv() and friends (though not in send() and friends). Alas, that PR is out of date (the recv() code was refactored somewhat) and someone would have to volunteer an updated version.

From internal sources (via @zooba) I understand that the general approach to this error is to retry (assuming it is intermittent or eventually a different error will occur) but there is currently no reproducer, which makes it hard to do create a test. I'm not sure if the proposed patch actually does that -- it seems as if it would cause recv() to return None, which I suspect most callers don't expect. So maybe the retry would have to be coded differently.

Anyway, @iUnknwn, from the logs you sent me privately it seems your problem is actually in accept(), which we should discuss in gh-93821.

Comments by @eryksun on gh-93821 suggest that this error code indicates a disconnect, so that suggests that recv() and friends are right in raising ConnectionResetError, although perhaps just returning b'' would also be acceptable -- that's what is returned for BrokenPipeError.

So I can think of two fixes:

• either we return b'' from recv() and friends (along the lines of the original discussion, @1st1 and @aeros);
• or we keep recv() etc. unchanged but catch, log and ignore errors in wait_closed().

Still not sure what to do, but I've rebased the PR so at least it can be tested.

@eryksun Do you have an opinion on the proposed PR (gh-93821)? Should we merge it and consider this fixed, or should we close the PR and take another approach to fix the issue?