fix(llc): adjust WebSocket disconnect order to prevent race conditions #2313
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
This commit addresses a race condition that could occur during the WebSocket disconnection process. The issue stemmed from the order of operations: 1. User was reset (`_user = null`). 2. Event monitoring was stopped. This order could lead to a situation where an reconnection was processed after the user was already null, causing a crash. The fix reverses this order: 1. Event monitoring is stopped (`_stopMonitoringEvents()`). 2. User is reset. This ensures that no reconnect attempts are made after the user object has been cleared, preventing the race condition.
WalkthroughThe internal logic of the WebSocket class was updated to add a guard in the reconnection method, preventing reconnection attempts when no user is set. The disconnect method was also reordered to set flags and stop event monitoring before clearing the user and closing the connection, ensuring consistent cleanup. Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant WebSocket
Client->>WebSocket: disconnect()
WebSocket->>WebSocket: Set _manuallyClosed = true
WebSocket->>WebSocket: Reset request flags
WebSocket->>WebSocket: Stop monitoring events
WebSocket->>WebSocket: Clear _user
WebSocket->>WebSocket: Close WebSocket channel
Note over WebSocket: Ensures proper cleanup and correct flag order
sequenceDiagram
participant WebSocket
participant Server
WebSocket->>WebSocket: _reconnect()
alt _user is null
WebSocket-->>WebSocket: Abort reconnection
else _user is set
WebSocket->>Server: Attempt to reconnect
end
Suggested reviewers
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
✅ Files skipped from review due to trivial changes (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (10)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #2313 +/- ##
==========================================
- Coverage 63.56% 63.55% -0.01%
==========================================
Files 409 409
Lines 25571 25572 +1
==========================================
- Hits 16253 16252 -1
- Misses 9318 9320 +2 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
renefloor
approved these changes
Jul 18, 2025
This was referenced Jul 25, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Submit a pull request
Fixes: #2303
Description of the pull request
This commit addresses a race condition that could occur during the WebSocket disconnection process.
The issue stemmed from the order of operations:
_user = null).This order could lead to a situation where an reconnection was processed after the user was already null, causing a crash.
The fix reverses this order:
_stopMonitoringEvents()).This ensures that no reconnect attempts are made after the user object has been cleared, preventing the race condition.
Summary by CodeRabbit