Sentry reporting thousands of {"isTrusted":false} errors without additional info

[AeonFr]

• [ x] Review the documentation: https://docs.sentry.io/
• [ x] Search for existing issues: https://github.com/getsentry/sentry-javascript/issues
• [ x] Use the latest release: https://github.com/getsentry/sentry-javascript/releases
• [ x] Provide a link to the affected event from your Sentry account: https://sentry.io/organizations/filmin/issues/2224953256/?project=5535515

Package + Version

• [x ] @sentry/browser
• @sentry/node
• raven-js
• raven-node (raven for node)
• other:

Version:

6.0.0

Description

We have had over 44k events in Sentry during a ~2 month period, in which the description of the event is simply:

{"isTrusted":false}

No additional data like stack trace is provided. We have the "Filter out errors known to be caused by browser extensions" and "Filter out known web crawlers" checkboxes enabled.

This kind of error is eating all of our monthly quota and there doesn't seem to be a way to disable. This doesn't work:

Sentry.init({
  // ...
  ignoreErrors: [
    '{"isTrusted":false}',
   // ...

I tried adding a beforeSend filter but I'm not sure how to filter these kind of errors. Some old issues have some code examples to filter or enhance these kind of errors (#2380, #2210), but they were written in previous releases of Sentry, so I though I would ask.

[tniemann]

hi,

same here. Any suggestions?

[AeonFr]

I tried lots of things but hadn't got anything useful.

These errors seem to bypass the standard beforeSend filter, for some reason. For example, If I add a console.log in that event, all the other errors display it, but these particular errors don't. Also adding filters based on stack trace, error message, or even using hint.originalException had no result.

Testing this has been a real pain because the only way to reproduce this errors is in production. I contacted support and they didn't offer any solution, although they do kindly suggested to give us some free extra quota as a compensation. But I'm afraid that free quota wouldn't last much anyway.

Sad to say this, but after all the effort of integrating Sentry into our workflow, we will have to go back to using Rollbar for now. We just can't afford to pay for +2K daily useless errors of this kind.

[kamilogorek]

The problem with such events is that due to dynamic nature of JS, everything can be thrown really, and it'll happily bubble up to the global error handler. Eg. throw new ErrorEvent('wat') or throw new EventTarget() despite being completely invalid, will still use the same mechanics. We cannot be too aggressive with filtering those ourselves, as there are legitimate use cases here as well, especially when working with 3rd party code.

These errors seem to bypass the standard beforeSend filter, for some reason

Every delivered event goes through this pipeline, so it's a matter of matching appropriate events.
Based on the OP event, it's JSON representation should define this filter to work:

Sentry.init({
  dsn: '...',
  beforeSend(event) {
    try {
      // or `event.exception.values[0].value.includes('isTrusted')` to be more lenient
      if (event.exception.values[0].value === "{\"isTrusted\":false}") {
        return null;
      }
    } catch (e) {
      return event;
    } 
    
    return event;
  }
});

[AeonFr]

I tried copy and pasting the exact code given earlier but the isTrusted error is still being reported.

I concluded that the beforeSend is being ignored because if, at the beginning of the beforeSend I place this:

console.log("xxxxxx")

No log is shown afterwards in the "breadcrumbs". Maybe there's a more accurate way to check if that code is being executed?

I forgot to mention but will put it here in case it has any relevance, I disabled the "TryCatch" integration in my Sentry setup. It looks like this:

  integrations: function (integrations) {
    integrations.push(new ExtraErrorData());
    integrations.push(new Debug());

    // integrations will be all default integrations
    return integrations.filter(function (integration) {
      // TryCatch adds a new frame to the stacktrace that
      // comes from a script of our domain. This change
      // causes conflicts with the ignore rules that try to
      // filter out errors from external domains. That's why it's disabled
      return integration.name !== "TryCatch";
    });
  },

[boserup]

We are having the same issue as reported by @AeonFr when embedding external content.
Have anyone figured out a nice solution to this?

[kamilogorek]

No log is shown afterwards in the "breadcrumbs". Maybe there's a more accurate way to check if that code is being executed?

beforeSend wont include any newly breadcrumbs. You need to explicitly modify event.breadcrumbs by hand and attach it there.

[AeonFr]

Thanks @kamilogorek, that insight was helpful to understand the problem.

Looks like my filter was not working because I was assuming the event message was a string. It's an object instead.

So this comparison:

if (event.exception.values[0].value === "{\"isTrusted\":false}") {

Should be:

if (JSON.stringify(event.exception.values[0].value) === "{\"isTrusted\":false}") {

Final filter should look like this:

beforeSend(event) {
    try {
      if (JSON.stringify(event.exception.values[0].value) === "{\"isTrusted\":false}") {
        return null;
      }
    } catch (e) {}

    // ...other filters...
    
    return event;
  }

I still believe the "Filter out errors known to be caused by browser extensions" and "Filter out known web crawlers" checkboxes should do this automatically, or there should be some way to set this automatically.

For example Rollbar filters this events by default, there's no way not to unfilter them in fact. For me, it's understood that an error from an external source that provides no information whatsoever should not be logged or stored. Is there's any use case from storing this errors? I can't think of any.

Still, I appreciate the help and I'm glad this got resolved and that we can continue our migration to Sentry 😌

[AeonFr]

I feel kinda' lame for realising this now, but if you configure the allowUrls rule to correctly match your domain(s), most of the isTrusted events will stop appearing as a side effect (because isTrusted is the error message of events triggered by external domains).

Hopefully this info is helpful for someone else, so you don't have to be touching your beforeSend rules so much!

[kamilogorek]

Well, yes, that makes it way more reasonable 😅 thanks for writing that down.

[boserup]

I feel kinda' lame for realising this now, but if you configure the allowUrls rule to correctly match your domain(s), most of the isTrusted events will stop appearing as a side effect (because isTrusted is the error message of events triggered by external domains).

Your filter in beforeSend is not really working for us. We are loading content into an iFrame with a Blob, so the error becomes:

Error: {"isTrusted":false}
  at None (blob:https://app-domain/ef693afd-98a0-4915-9c2f-cfb17a1f5db9)

It is not really an option to block errors from our app domain or the blob. Since this is rapidly eating away our quota, I would really like to find a viable solution for this.
Do you have any suggestions @AeonFr?

[kamilogorek]

@boserup this should work just fine with blob URLs as well - #3217 (comment)

If not that, you can do any other assertion there that will match on an event, or originally caught exception (using hint.originalException:

Sentry.init({
  dsn: '...',
  beforeSend(event, hint) {
    if (hint.originalException) {
      // this is what has been caught by `onerror` handler
    }
    
    return event;
  }
});

[AeonFr]

I wasn't able to fix the issue until I correctly learned how to debug the error message.

Instead of using console.log, I used this code to debug:

beforeSend() {
  event.breadcrumbs.push({
        level: Sentry.Severity.Debug,
        message: `Event exception value: ${JSON.stringify(
          event.exception.values[0].value
        )}`,
      });

  // ...

This is the code that helped me realise event.value was an object and not a JSON string. But using similar code you could debug other aspects of the error until finding something useful for filtering.

Hope it's helpful, let me know if you find a solution