WebSocket close by remote server results in non-graceful disconnection
Closed this issue · 6 comments
In 0.2.2 I'm observing that a WebSocket close initiated by the remote server results in a non-graceful Disconnected event. As far as I can tell this is a regression relative to 0.2.1.
This appears to be due to a small change in the main session run() loop, where an is_active check was removed in the no data case. I believe this case is triggered when the socket is closed because the selector triggers as readable, but there is no data. See the change here on lines 398-400 on the left-hand side. Restoring these lines appears to fix the issue.
I'm attaching a test case that should produce non-graceful behavior. This is based on test_simple_run() from test_session.py, but adds the necessary bytes for a close to the payload. Also, note the session.websocket.state.session = session code on line 45 of the diff file. This feels pretty hackish but without it I ran into a different issue about not being able to set the sent_close_time in WebSocket.close() because the session was not defined in the WebSocket state.
I guess that's on Windows again?
For sure on Windows. I did a very quick test and I believe I'm observing it on Linux (CentOS 7) as well.
Thanks. Released 0.2.3 with the fix.
Actually, there may be a deeper issue that that. The test passes, but I see non graceful closes when it should be graceful.
FWIW, I tested the new 0.2.3 release with the simple experiment where I first noticed this and I'm now seeing graceful closes. This is on both Windows and Linux. I'm happy to run some further experiments if that might help get to the bottom of this, but for now I'm not sure of the conditions needed to produce a non-graceful case.
My mistake. The server I was testing against was doing a non-graceful close. Lomond was doing the right thing.