Skip to content
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

Errors thrown in globalEventProcessors are silently ignored #2212

Closed
3 of 4 tasks
mogelbrod opened this issue Aug 22, 2019 · 3 comments · Fixed by #2416
Closed
3 of 4 tasks

Errors thrown in globalEventProcessors are silently ignored #2212

mogelbrod opened this issue Aug 22, 2019 · 3 comments · Fixed by #2416

Comments

@mogelbrod
Copy link

Package + Version

@sentry/browser@5.6.2

Description

Errors thrown in global event processors are picked up by the Sentry lib, initiating another error capture which in turn calls the same global event processor that will throw an error once more. This repeats for an unknown number of times (until the stack overflows perhaps?). The issue is that there's no trace of the original error, nor any subsequent errors thrown by the faulty global event processor. Sentry is obviously unable to send the error upstream, but nothing is logged either.

Discovering that a faulty global event processor was preventing any of our errors from being reported took some time, so it would be great if the SDK could detect and log these errors automatically. Until then I recommend wrapping the processing code in a try/catch block and manually log errors:

Sentry.addGlobalEventProcessor(event => {
  try {
    event.missingProperty.assignment = true
  } catch (err) {
    console.error('sentry global event processor threw error', err)
  }
  return event
})
@kamilogorek
Copy link
Contributor

I wasn't able to loop it as described, however I can confirm that the error is swallowed (it shoudn't, as we have a large catch clause in our promise chain 🤔). I'll investigate it soon. Thanks for the report.

@mogelbrod
Copy link
Author

@kamilogorek did you get around to looking into this issue?

@kamilogorek
Copy link
Contributor

@mogelbrod currently you'll get a debug log when you set debug: true and something fails.
Just implemented better solution here #2416

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants