-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Refactor: Replace mutex.lock() with mutex.withLock() #18067
Conversation
…ck and remove finally.
📲 You can test these changes on Jetpack by downloading jetpack-installable-build-pr18067-1b5e1f3.apk
|
📲 You can test these changes on WordPress by downloading wordpress-installable-build-pr18067-1b5e1f3.apk
|
Generated by 🚫 dangerJS |
Note: Moved to a draft PR. Although all the current tests pass, there is still some uncertainty as to whether this will make a difference. |
I think these days "I feel in better shape" to retry simulating this error via TDD. Will try to find some time this week or next week to dedicate to this 🙇🏻 Thanks for drafting this PR @zwarm ! |
@zwarm Let's try this out, it can't hurt 👍🏻 Plus, GPT subscribes: |
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.
LGTM
IMHO it can't hurt to try this out, we'll keep monitoring the crash frequency and see if it actually does fix the issue.
Parent #17463
(CompletionHandlerException: Exception in resume onCancellation handler for CancellableContinuation(DispatchedContinuation[Dis...)
The goal of this PR is to try and fix the
IllegalStateException: Mutex is not locked
issue that occurs when uploading local changes.The intent is to change from using
mutex.lock()
tomutex.withLocking()
. This should ensure that we have access to the locked mutex before trying to unlock it. The theory behind this is that we may be experiencing a race condition sincemutex.isLocked()
only gives us the "at this moment" answer, another process could have come in before we get to the unlock.Using
withLock
should automatically manage the locking/unlocking of the mutex, and in addition, we can call mutex.unlock() when we experience aCancellationException
without needing to check theisLocked
beforehand.If anyone thinks this is a bad idea, we can nix it. Figured it was worth a try. :)
To test:
There is nothing specific to test; as we haven't been able to reproduce this crash.
Please take the apps out for a generic spin - create/update some posts, turn networking on/off, etc.
Regression Notes
Potential unintended areas of impact
N/A
What I did to test those areas of impact (or what existing automated tests I relied on)
N/A
What automated tests I added (or what prevented me from doing so)
N/A
PR submission checklist:
RELEASE-NOTES.txt
if necessary.