Repository navigation
asyncio DatagramProtocol stops calling callbacks after OSError, on Windows #88906
Closed as not planned
Description
| BPO | 44743 |
|---|---|
| Nosy | @asvetlov, @1st1, @sim1234, @JulianOrteil |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2021-07-26.14:50:58.620>
labels = ['type-bug', '3.9', 'expert-asyncio']
title = 'asyncio DatagramProtocol stops calling callbacks after OSError'
updated_at = <Date 2021-11-14.20:12:24.291>
user = 'https://github.com/JulianOrteil'bugs.python.org fields:
activity = <Date 2021-11-14.20:12:24.291>
actor = 'sim1234'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['asyncio']
creation = <Date 2021-07-26.14:50:58.620>
creator = 'JulianOrteil'
dependencies = []
files = ['50183']
hgrepos = []
issue_num = 44743
keywords = []
message_count = 2.0
messages = ['398229', '406332']
nosy_count = 5.0
nosy_names = ['asvetlov', 'yselivanov', 'sim1234', 'Thomas Trummer', 'JulianOrteil']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue44743'
versions = ['Python 3.9']
Activity
JulianOrteil commentedon Jul 26, 2021
After working through the Transports and Protocols documentation of asyncio, I decided to stress test the DatagramProtocol as an application I'm developing needs to act as a UDP server.
One of my tests drops the client before the server responds which raises an OSError on the server; however, after the error is raised, the server stops executing callbacks (like connection_made, datagram_received, error_received and connection_lost) until it is restarted. There is no documentation I can find that explains this behavior nor is there any meaningful discussions about it elsewhere. I don't think the socket itself drops because the client doesn't raise an OSError itself when connecting to the now-errored server.
Interestingly though, when I tried to enable debug mode of the loops on both the client to see if there were any silent errors being raised (which didn't occur), this issue doesn't occur. Enabling debug mode on the server had no effect.
Attached is the reproducible code; it is a slightly modified version of the UDP Echo Client/Server example found in the docs named above. My environment is Python 3.9.5 on Windows 10.
sim1234 commentedon Nov 14, 2021
I'm experiencing the same exact issue. The bug manifests with all combinations: SelectorEventLoop and ProactorEventLoop, python 3.9 and 3.10, on Windows 10. Python 3.8 on Linux seems to not be affected. Can we get a fix or at least an update?
AdjWang commentedon Jun 25, 2022
Same issue using python 3.10 on windows 10. The issue can also happen on the client-side.
During the client and server exchanging messages, I restarted the server process. The client raised "OSError: [WinError 1234] No service is operating at the destination network endpoint on the remote system", then it stopped receiving messages even after the server process restarted.
However the sending on the client-side is still working since the restarted server can receive messages from the client.
[-]asyncio DatagramProtocol stops calling callbacks after OSError[/-][+]asyncio DatagramProtocol stops calling callbacks after OSError, on Windows[/+]kumaraditya303 commentedon Nov 1, 2024
Duplicate of #91227