zinnia: fix double reporting of crash errors #434
Conversation
juliangruber
commented
Apr 26, 2024
•
juliangruber
commented
- swap sentry token
lib/zinnia.js
Outdated
| @@ -276,6 +279,8 @@ const catchChildProcessExit = async ({ | |||
| maybeReportErrorToSentry(moduleErr) | |||
| }) | |||
| } | |||
| // If it should be reported, it was already handled | |||
| err.reportToSentry = false | |||
There was a problem hiding this comment.
I am a bit confused about why we are reporting the error to Sentry twice. Shouldn't we fix that instead of adding a new flag to the error object?
The condition at the top of this file checks err.shouldReportToSentry, but this code is setting err.reportToSentry.
How can we (manually) verify that the changes in the pull request work as intended?
There was a problem hiding this comment.
I am a bit confused about why we are reporting the error to Sentry twice. Shouldn't we fix that instead of adding a new flag to the error object?
Absolutely, we're fixing it by adding the flag :D Or at least that's the plan.
The problem is this: There's an inner try/catch and an outer try/catch. The inner try/catch reports the error to Sentry. It then also throws the error, because that is required for control flow (so that the outer loop ends). In this outer loop, we're catching all errors and reporting them to Sentry. By adding the flag we're telling the outer catch handler that the error has already been submitted to Sentry.
Do you have another suggestion how to implement this?
|
I have changed the sentry key and disabled the old one |
There was a problem hiding this comment.
I prefer slightly more reportedToSentry over reportToSentry for the following reasons:
reportedToSentrydescribes what happened. When nobody reads/interprets this field, then it's ok - we are telling what happened, not asking what to do- I understand
reportToSentryas a command asking some other piece of code to report this error to Sentry. If that other piece of code does not report the error, then this command will be unfulfilled.
I also find it a bit weird when a property has a default value of true.
At the same time, this is subjective and a minor detail, so I am okay with landing this PR as it is now.
