-
Notifications
You must be signed in to change notification settings - Fork 57
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
[MM-54328] Fix call state race condition #512
Conversation
fetchChannelData(currChannelId).then((actions) => | ||
store.dispatch(batchActions(actions)), | ||
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am removing this as I don't think it's needed anymore. We fetch all channels/calls anyway on first load and then rely on websocket to keep things up to date. I couldn't see any side effect so far but will need to monitor.
Codecov ReportPatch coverage has no change and project coverage change:
Additional details and impacted files@@ Coverage Diff @@
## main #512 +/- ##
========================================
- Coverage 5.43% 5.42% -0.02%
========================================
Files 24 24
Lines 4378 4387 +9
========================================
Hits 238 238
- Misses 4123 4132 +9
Partials 17 17
☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like it will simplify things, thank you!
Summary
PR fixes a race condition that could cause the call state to be incorrectly updated with stale data. Contrary to what I originally thought, this didn't happen on join. In fact, we don't fetch the call state when joining but when switching channel. So if switching to the channel the call was ongoing while some other users were joining, it could happen (actually quite easy to reproduce) that the final state missed some profiles.
The solution here is to send the whole call state through the websocket channel upon joining the call. This ensures the call is up to date as other events are guaranteed to be received in order.
To be noted, this PR only fixes the above case of joining a call. There are still a few possible races when loading Mattermost the first time. Unfortunately this includes opening the popout window although I couldn't easily reproduce this case so far. To fix that we likely need something a bit more involved because it's not straightforward to guarantee sequencing of events there. Need to think it a bit more.
Ticket Link
https://mattermost.atlassian.net/browse/MM-54328