-
-
Notifications
You must be signed in to change notification settings - Fork 83
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
PollingBlockTracker: Stop wrapping errors #310
base: main
Are you sure you want to change the base?
Conversation
We do not presently use this class in any repo under the MetaMask organization. In general we have found a polling-based approach to be more reliable than a subscription-based approach.
If PollingBlockTracker fails to make a request, the error is wrapped with a marker a more descriptive message (including the stack trace) before being emitted under the "error" event or logged. This wrapping may have been added in the past to assist with debugging, but it is not necessary now, and it complicates the tests.
console.error(newErr); | ||
this.emit('error', error); | ||
} catch { | ||
console.error(`Error updating latest block: ${getErrorMessage(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.
Question: Do we even need to log the error anymore? Can we just let the error be thrown here if there are no "error" listeners? (This error would manifest as an unhandled rejection, but we could catch it in the polling loop so it doesn't leak out.)
); | ||
}); | ||
|
||
it(`should emit the "error" event (added via \`${methodToAddListener}\`) and should not throw if, while making the request for the latest block number, the provider throws a string`, async () => { |
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.
Previously we had tests which verified that the error message produced when the thrown error was a string was different from when the thrown error was an Error. Because we've simplified how error messages are stringified, we don't need to do this anymore.
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!
If PollingBlockTracker fails to make a request, the error is wrapped with a marker and a more descriptive message (including the stack trace) before being emitted under the "error" event or logged. This wrapping may have been added in the past to assist with debugging, but it is not necessary now, and it complicates the tests.