-
Notifications
You must be signed in to change notification settings - Fork 65
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-54157] Fix potential nil access upon starting a recording #495
Conversation
// Sending the event prior to making the API call to the job service | ||
// since it could take a few seconds to complete but we want clients | ||
// to get their local state updated as soon as it changes on the server. | ||
p.publishWebSocketEvent(wsEventCallRecordingState, map[string]interface{}{ | ||
"callID": callID, | ||
"recState": recState.getClientState().toMap(), | ||
}, &model.WebsocketBroadcast{ChannelId: callID, ReliableClusterSend: true}) | ||
|
||
// We don't want to keep the lock while making the API call to the service since it | ||
// could take a while to return. | ||
p.unlockCall(callID) |
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.
Unrelated to the panic but since we moved to the new job API we don't need to do this, the stop action is completely asynchronous and safe to be called under lock.
if recState.JobID != jobID { | ||
p.LogInfo("a new job has started in between, exiting", "callID", callID, "jobID", jobID) | ||
return | ||
} |
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.
Adding an extra check to avoid making potentially inconsistent state updates due to previously failed jobs. Ideally we'd cancel this timeout check whenever we stop a recording but the synchronization needed would make the code more complex so it seems like a few extra goroutines that return early are not too bad.
Codecov ReportPatch coverage has no change and project coverage change:
Additional details and impacted files@@ Coverage Diff @@
## MM-53162 #495 +/- ##
===========================================
+ Coverage 5.39% 5.45% +0.05%
===========================================
Files 23 23
Lines 4297 4309 +12
===========================================
+ Hits 232 235 +3
- Misses 4047 4057 +10
+ Partials 18 17 -1
☔ View full report in Codecov by Sentry. |
… state operations (#460) * Refactor cluster mutex * Call locking utils * Add/remove session * Mute/Unmute,RaiseHand/LowerHand,ScreenSharing * Call start post * Call end * Enable/disable calls * Recording API * Remove unused functions * Mutex metrics * Lint fixes * Update .golangci.yml * Writer DB * Simplify call lock use * Simplify call start case * Fix KVGet semantic in case of no results * Small tweaks * Make Unlock() actually safe * Simplify recording API handlers * Move code around * Prevent logging errors on duplicate session removals attempts * Enforce maxPollInterval * Add note to cleanCallState function * Use channelID instead of callID * Update new code * [MM-53167] Persist participants list (#486) * Persist list of participants on call end * Exclude bot from participants list * Fix potential nil access upon starting a recording (#495) * fix linter errors * Bump golangci-lint version * Force input * Revert "Force input" This reverts commit 0b22839. --------- Co-authored-by: Christopher Poile <[email protected]>
Summary
PR fixes a potential panic due to accessing a
nil
recState
.Ticket Link
https://mattermost.atlassian.net/browse/MM-54157