-
-
Notifications
You must be signed in to change notification settings - Fork 757
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WebSockets 11.0 broke Uvicorn test suite #1927
Comments
I bisected the failure to: python-websockets/websockets@5113cd3 This commit creates a subtle change in the timing of how connections are closed: it's happening faster in 11.0 because the overhead of creating an asyncio task is removed. This would explain why #1929 (comment) reports that the connection reaches the CLOSING state with 11.0 while it's still OPEN with 10.4. |
The docstring says:
The test includes an ASGI callable that returns something other than None. So we expect the connection to be closed with an error condition, but it doesn't anymore. I believe that the test is still valid and the code no longer works as expected with websockets 11.0. In this context, "error condition" could be interpreted in different ways. It could mean "no closing handshake" (which was the behavior with websockets 10.4) or "closing handshake with an error code" (close code 1011 with an explicit error message would make sense here). As a reminder, close code 1006 is a synthetic code for "TCP connection was closed brutally, there was no close coed". I looked at the ASGI spec but didn't find anything about the return value of the ASGI callable. I'm mentioning this in case it opens easier ways to fix the issue. |
It's just that we enforce the interface: async def app(scope, receive, send) -> None:
... Thanks. I'll take a look. |
I bumped the log level and captured these logs of a failing test:
We have the debug logs of the client but not of the server. I see the following sequence here with websockets 11.0:
With websockets 10.4, I'm getting this:
This error looks like the server attempts a closing handshake but closes the TCP connection before he can get the handshake response from the client. This wasn't a good behavior in the first place: if we're going to close the connection brutally, we shouldn't send a "1000 normal closure" close code. |
As the title says... Changelog: https://websockets.readthedocs.io/en/stable/project/changelog.html
The text was updated successfully, but these errors were encountered: