feat(socketio): notify client of transport completion #449
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Are there any remaining problems with this? |
ctrlaltf24
approved these changes
Sep 20, 2024
ctrlaltf24
reviewed
Sep 20, 2024
There was a problem hiding this comment.
suggestion: would be nice to have a test for this before merging @sirkrypt0
| // We don't need to do that in the other cases, since proper server close | ||
| // and manual client close are handled explicitly. | ||
| if let Some(err) = client_clone | ||
| .callback(&Event::Close, "transport close") |
There was a problem hiding this comment.
nit: constant for this message
There was a problem hiding this comment.
I added a new CloseReason enum and used the appropriate values wherever the Event::Close was emitted. This should make it more consistent and easier for clients to distinguish the close reasons.
I'm not sure if the event.rs file is the correct location for that, but since it's closely related to the Event::Close I thought it may be fitting.
sirkrypt0
force-pushed
the
feature/notify-on-unknown-disconnect
branch
3 times, most recently
from
6d21908 to
8605ca8
Compare
ctrlaltf24
approved these changes
Sep 23, 2024
When the async client connects to the server, it spawns a new thread to
handle the arriving messages asynchronously, which is immediately
detached with no chance of awaiting its completion.
For long-running programs (e.g. a client program that never really disconnects
from the server) this can be problematic, as unexpected stream completions
would go unnoticed. This may happen if the underlying tungstenite websocket
shuts down ('Received close frame: None') but there are no engineio/socketio
close frames. Hence, since the stream terminates, the message handling task
stops without a Close or Error event being fired.
Thus, we now fire an additional Event::Close when the stream terminates,
to signal the (potentially unexpected) close to the user.
Previously, when we emitted an Event::Close, we didn't specify a reason for why this event was emitted. When implementing the close notification on unexpected transport closes, we started sending 'transport close' as the payload for the close event. We now decided to do this more consistently and added a close reason when emitting the Event::Close, so that the client better knows why this event was emitted.
sirkrypt0
force-pushed
the
feature/notify-on-unknown-disconnect
branch
from
8605ca8 to
0540579
Compare
ctrlaltf24
approved these changes
Sep 24, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When the async client connects to the server, it spawns a new thread to handle the arriving messages asynchronously, which is immediately detached with no chance of awaiting its completion.
For long-running programs (e.g. a client program that never really disconnects from the server) this can be problematic, as unexpected stream completions would go unnoticed. This may happen if the underlying tungstenite websocket shuts down ('Received close frame: None') but there are no engineio/socketio close frames. Hence, since the stream terminates, the message handling task stops without a Close or Error event being fired.
Thus, we now fire an additional Event::Close when the stream terminates, to signal the (potentially unexpected) close to the user.
Closes #448
Once we settle on a final solution, I can also write a test for that.