Browser extension errors still logged, despite inbound setting and allowUrls

[futzlarson]

Is there an existing issue for this?

• I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• I have reviewed the documentation https://docs.sentry.io/
• I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Sentry Saas (sentry.io)

Which package are you using?

@sentry/angular

SDK Version

Latest

Framework Version

No response

Link to Sentry event

https://auxbus.sentry.io/issues/3706814090/?project=1375267&query=is%3Aunresolved&referrer=issue-stream

SDK Setup

        Sentry.init({
            // allowUrls: [] This is set, but leaving out
            // ignoreErrors: [] This is set, but leaving out

            release: '{{ release() }}',
            environment: '{{ App::environment() }}',

            replaysSessionSampleRate: {{ prod() ? '0.1' : '1.0' }},
            replaysOnErrorSampleRate: 1.0,
            integrations: [
                new Sentry.Integrations.Replay({
                    maskAllText: false,
                    blockAllMedia: false
                })
            ]

Steps to Reproduce

Issue is Non-Error promise rejection captured with value: null. Confirmed this is caused by a browser extension (1Password and Buffer - almost certainly 1Password) because once the user disabled them, the error went away. Only thing is, I have this on:

And allowUrls set. Shouldn't either of these options prevent this?

I can add this error to ignoreErrors, but I shouldn't have to, right? See #3451

Expected Result

Unimportant errors from extensions ignored.

Actual Result

Errors not ignored.

[Lms24]

Hi again @futzlarson,

I think we don't have this error message in our "known browser extenstion" error filter which means that enabling this option in the UI won't have an effect for this error.

allowUrls only checks the URLs of the stack frames. Since this error doesn't have a stack trace, we can't check against it.

That leaves us with ignoreErrors which - as you said - should work to filter out this error message.

An alternative would be to configure your beforeSend function to check if the error event has this error message and no stack trace, in which case you return null to discard it.

Does this answer your question?

[futzlarson]

Interesting idea about beforeSend. What exactly does an error not having a stack trace mean? I wonder if I could just ignore all errors without one as a way to ignore errors from extensions.

[Lms24]

Errors without stack traces can mean a lot of things. As we can see here, they could originate from browser extensions. In the past, we observed certain fetch errors that didn't have stack traces but we couldn't reproduce them reliably to find a fix. We have a couple of open discussions and issues (e.g. #5334, #4146) around this topic and it's on our mind to improve this (we tried before). However, it's a hard problem to solve and there probably isn't a universal solution.

As for your question, I think it depends a lot on your app if you filter them out entirely. My suggestion would be to go slow and see what you can eliminate but feel free to experiment :)

The error message you reported, seems to be quite generic, so I'm afraid we can't just add it to our default filters without filtering out false negatives. I'm going to close this issue as I don't think there's something actionable at this point but feel free to leave a comment if you think this should be reopened.