Sentry-javascript: Errors inside raven swallow the original error

[axnsan12]

Using raven-js 3.24.0 installed via npm, in Angular 5.

What is the current behavior?

If an error happens while reporting an event to sentry, raven blows up and throws an error in the console. For example, if I have origin filtering enabled on sentry and run my website locally, raven receives a 403 and swallows the original exception.

What is the expected behavior?

Raven should never do anything that prevents the real error from reaching termination, i.e. the application error should always be rethrown. If an error hapens in raven code, it should be caught, logged and the app's error be rethrown.

[axnsan12]

Related issue from raven-node: https://github.com/getsentry/raven-node/issues/253

[kamilogorek]

@axnsan12 I reevaluated this issue again after trying to approach it more generically in the PR above, and I realized that it's not the issue of Raven.js.

First thing is that we already do cover 403s here - https://github.com/getsentry/raven-js/blob/master/src/raven.js#L2055-L2072

However, when you take a look at your stacktrace, the error is not originating from there, but from those lines https://github.com/getsentry/raven-js/blob/master/src/raven.js#L1364-L1367

Which on the other hand is calling zone.js method here - https://github.com/angular/zone.js/blob/master/dist/zone.js#L1048-L1067
zoneify is a function that wraps all native methods, and one of them is, well, fetch.

There's something wrong going on with the wrapping in this library, not in our implementation.

I created a boilerplate Angular 5 setup with the Raven, blocked my domain and 403 was handled correctly (trigger onError callback and log the error back to console), without any issue.

I'm more than happy to take a look at it once again, but I'd need you to provide a reproducible codebase that I could use to trigger this error.

[axnsan12]

https://github.com/axnsan12/raven-swallow

This shows the issue I'm talking about. Relevant code is in app.module.ts and app.component.ts.

[kamilogorek]

Ok, let's dissect what's happening here, as everything is working just fine, but manual rethrows make it look odd (ignore my previous comment, zone.js just made it harder to debug due to its "wrap everything i can" nature).

• call Raven.config().install()
• throw an error in the component
• error is caught by handleError method
• call Raven.captureException(err);, it's sent to sentry (403 is not that important here)
• then rethrow this error with throw err;

And now, what's actually happening:

• by calling install() you attach global error handlers
• when doing captureException inside your handleError method, you capture it with Raven
• when you rethrow it, it's not captured by handleError method anymore, as it's not in the bubble chain - what happens then, is that error is caught by global onerror handler that you attached using install() method
• our onerror handler captures your rethrow and tries to send it
• however, because it's the very same error that you just caught yourself, it's deduped and dropped (see allowDuplicates option - https://docs.sentry.io/clients/javascript/config/)
• you don't see any logging, because you don't use debug mode as described in our docs (please note that previous method - Raven.debug = true was broken in TypeScript which you use, so you can use Raven.config(DSN, { debug: true }) now with newest 3.24.2 release as well)

---

Here is how your console will look in various configurations (note that I used 401 [invalid dsn] to simulate 403 behavior - it will be the same).

---

// No `install` - rethrown error wont be caught
Raven.config(DSN)

---

// No `install` - rethrown error wont be caught
Raven.config(DSN, {
  debug: true
})

---

// Current behavior
Raven.config(DSN).install()

---

Raven.config(DSN, {
  debug: true
}).install()

---

Raven.config(DSN, {
  allowDuplicates: true
}).install()

---

Raven.config(DSN, {
  allowDuplicates: true,
  debug: true
}).install()

---

Hopefully it makes everything much clearer. Let me know if you have any more questions.

[axnsan12]

OK, thanks for your explanation, that at least clears up what's happening!

Unfortunately, that still seems subpar to me - in the bottom screenshots with debug: true, the original exception is still nowhere to be seen in the console, unless you dig into the "Raven about to send" log messages. Enabling debug also has the disadvantage of polluting the console with unrelated/undesired messages from raven.

Even when Raven is installed as global onerror handler, it should always act as a passive observer - I'm not really interested in the raven failure, I'm interested in seeing my error in the log, no matter where it originated - if it would have bubbled up to the console without Raven, it should also do so with it installed.

Note that duplication is not the issue here, because as you said the captureException call is redundant, my concerns are the same even after removing it.

[john-kurkowski]

Yeah, nice breakdown, @kamilogorek. I think that'll serve readers for time to come, even for those without this exact issue.

One nitpick:

you don't see any logging, because you don't use debug mode as described in our docs

The docs say

debug

If set to _true_, Raven.js outputs some light debugging information onto the console.

This doesn't tell me what I'm going to get. Will the debugging information be for me? For my users? For Raven.js developers? Should I avoid in production? Will it print the original error?

That last one is the reason I came to this thread. I was hoping for such an option.

[itbrandonsilva]

Also looking to know the same as @john-kurkowski .

[kamilogorek]

It can be done through event processor and hints in new SDK.