Skip to content

asyncio DatagramProtocol stops calling callbacks after OSError, on Windows #88906

Description

@JulianOrteil
BPO 44743
Nosy @asvetlov, @1st1, @sim1234, @JulianOrteil
Files
  • reproducible_datagramprotocol_error.py: Reproducible code
  • 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

    1. JulianOrteil commented on Jul 26, 2021

      JulianOrteilmannequin
      MannequinAuthor

      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.

    2. sim1234 commented on Nov 14, 2021

      sim1234mannequin
      Mannequin

      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?

    3. transferred this issue fromon Apr 10, 2022
    4. AdjWang commented on Jun 25, 2022

      @AdjWang

      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.

    5. changed the title [-]asyncio DatagramProtocol stops calling callbacks after OSError[/-] [+]asyncio DatagramProtocol stops calling callbacks after OSError, on Windows[/+] on Aug 25, 2022
    6. kumaraditya303 commented on Nov 1, 2024

      @kumaraditya303
      Contributor

      Duplicate of #91227

    7. moved this from Todo to Done in asyncioon Nov 1, 2024
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    No one assigned

      Projects

      • Status
        Done

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions