-
-
Notifications
You must be signed in to change notification settings - Fork 26
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
get_message() sometimes missing close reason #158
Comments
Thank you for reporting. Are you doing anything special on the other end to make this happen? |
It's concerning, since the implementation is often using if self._close_reason:
raise ConnectionClosed(self._close_reason) |
Nope, the other side is a 3rd party API. I have a) a receive task that consumes messages from the websocket and pushes them to my own MemoryReceiveChannel, b) a send task that pushes out messages with Here's my receive function in full:
|
Perhaps it's happening in this path, where there is a context switch ( I may not have time to address it for a while-- help appreciated (debug, write a test, verify autobahn test suite, etc.). |
I think you can confirm the problem source by instrumenting trio-websocket as follows, and run your sleep(1) example. async def _handle_close_connection_event(self, event):
self._for_testing_peer_closed_connection.set()
print('_handle_close_connection_event() sleep')
await trio.sleep(0)
if self._wsproto.state == ConnectionState.REMOTE_CLOSING:
print('_handle_close_connection_event() send response')
await self._send(event.response())
print('_handle_close_connection_event() set reason')
await self._close_web_socket(event.code, event.reason or None) |
the example client has this exception after executing the
|
The problem seems to have been introduced way back in #79 ("Delay connection closed") |
Instrumenting my client:
|
So the problem is happening prior to the close connection handler-- that's helpful, thank you. |
Pending PR #159 fixes the case in the example client @pikeas in your example would you print the |
Also, I may have missed it, but would you clarify which side is closing the connection in your case? |
Reason is
I'm calling Hope this helps, I'll try the PR when it lands! |
Also, |
oh, if you're calling perhaps you could confirm the fix by installing it from source:
|
Confirmed, with the new branch I'm seeing |
Thank you for confirming. Please give me some time to write tests, merge, and release. I'm still concerned about a possible regression, since internally the code often uses |
the scope of the bug is wider than just the timing of setting the This will cause |
During a local-initiated close handshake, the following incorrect behavior was observed: * `closed` attribute would be `None` * `send_message()` would be silently ignored (wsproto < 0.2.0) or leak a `LocalProtocolException` (wsproto >= 0.2.0) Upon local-initiated close, `closed` will now have the reason, and `send_message()` will raise `ConnectionClosed`. Fixes #158.
There appears to be some sort of race condition between closing the memory channel and setting
_close_reason
.The text was updated successfully, but these errors were encountered: