-
Notifications
You must be signed in to change notification settings - Fork 5k
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
Bug: Mutex locks not released on error #4557
Conversation
@frankiebee you were working on this sort of thing before, so you might be interested in these changes |
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.
Looks good. I had some questions about one of the changes (txStateFailed threw errors?), but nothing that looks dangerous or bad. Has some important improvements that I'd love to ship asap.
try { | ||
this.txStateManager.setTxStatusFailed(txId, err) | ||
} catch (err) { | ||
console.error(err) |
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.
Should use log.error()
this.txStateManager.setTxStatusFailed(txId, err) | ||
// this is try-catch wrapped so that we can guarantee that the nonceLock is released | ||
try { | ||
this.txStateManager.setTxStatusFailed(txId, err) |
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.
Was setTxStatusFailed()
throwing uncaught errors? Looking at it, it seems so straight forward. In fact, even its own internal _setTxStatus(id, status)
method has its own try/catch.
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 treated it as a black box and assumed errors could come from it
its possible errors could come from an eventemitter handler
return { nextNonce, nonceDetails, releaseLock } | ||
} catch (err) { | ||
// release lock if we encounter an error | ||
releaseLock() |
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 a great candidate for the approved
bug, I'm so excited to see you find this.
@@ -466,7 +462,7 @@ module.exports = class MetamaskController extends EventEmitter { | |||
* @param {} seed | |||
*/ | |||
async createNewVaultAndRestore (password, seed) { | |||
const release = await this.createVaultMutex.acquire() | |||
const releaseLock = await this.createVaultMutex.acquire() |
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.
Very readable renaming.
theres some style changes for consistency, the biggest change is the addition of 2 try-catchs where we were doing things that could error |
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.
Looks good to me. I lack deep context here but the changes make sense if errors are being thrown from setTxStatusFailed
, getNonceLock
, and / or createNewVaultAndKeychain
.
const release = await this.createVaultMutex.acquire() | ||
let vault | ||
|
||
const releaseLock = await this.createVaultMutex.acquire() |
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.
Can the mutex acquisition ever fail? Should we move this asynchronous operation inside the try / catch as well, or is that overly-cautious?
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.
acquisition should never fail
Fixes #4343
Auditing and fixing use of locks: