fix(client-ws-transport): Flush send queue in close() to avoid race #9101
Conversation
This file contains hidden or 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
Before this there were a race between `setTimeout` in `sendMessage` and `close`. Even for a good citizen, that calls `unsubscribe()` and awaits result there were no synchronization between unsubscribe adding message to `messageQueue` and restarting timer, and actually sending this message to WebSocket. When `close()` is called close frame is sent immediately to WebSocket. If at that moment messageQueue is not empty, and timer is armed it can wake up, and discover socket in CLOSING state: send side closed, recv side open. For now - just flush everything queued, and send close frame after, so it would look like close was queued after. More complete solution is to add synchronization between unsubscribe call and sending message, or even receiving ack for it.
Contributor
Author
|
The only failure is Firebolt integration tests, they are broken right now and is being diagnosted. I'll land this as is, to unstuck CI checks in other PRs. |
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.
Check List
Description of Changes Made (if issue reference is not provided)
Before this there were a race between
setTimeoutinsendMessageandclose. Even for a good citizen, that callsunsubscribe()and awaits result there were no synchronization between unsubscribe adding message tomessageQueueand restarting timer, and actually sending this message to WebSocket. Whenclose()is called close frame is sent immediately to WebSocket. If at that moment messageQueue is not empty, and timer is armed it can wake up, and discover socket in CLOSING state: send side closed, recv side open.For now - just flush everything queued, and send close frame after, so it would look like close was queued after. More complete solution is to add synchronization between unsubscribe call and sending message, or even receiving ack for it.