Improve reporting of chrome extension errors (and possibly others)?

[lobsterkatie]

• Review the documentation: https://docs.sentry.io/
• Search for existing issues: https://github.com/getsentry/sentry-javascript/issues
• Use the latest release: https://github.com/getsentry/sentry-javascript/releases
• Provide a link to the affected event from your Sentry account

Package + Version

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

Version:

5.10.2, but nothing has changed as of 5.11.0

Description

In certain circumstances, Chrome throws an Extension context invalidated error. Though it's an actual Error object, including a stacktrace, it wraps that Error object in a CustomEvent with the following structure:

{
  currentTarget: <object>, 
  detail: 
  {
    promise: <object>,
    reason: <the Error object including stacktrace>
  },
  isTrusted: <boolean>, 
  target: <object>, 
  type: unhandledrejection
}

As a result, when it comes through to Sentry, it gets lumped with all other CustomEvent events, under the heading Non-Error promise rejection captured with keys: currentTarget, detail, isTrusted, target. Though the original error and its stacktrace are visible in the Additional Data section of the event details page, the fact that it lives there means it's not subject to the normal grouping/filtering/etc mechanisms.

In this particular example, that of the Extension context invalidated error, it's likely that this would always be considered noise, as, unless you are the extension developer themselves, you probably don't care that your end user happens to be running some third-party extension which has had a problem. In that case, even with the nested structure, these errors can be filtered out using the code mentioned here.

However, it's an open question whether other, potentially-useful errors also come wrapped up this way, and if this is a common enough occurrence that it's worthwhile to have the SDK unwrap them automatically, so that they can be treated as full, first-class errors. (In the meantime, code to do this unwrapping manually in beforeSend is attached in a comment below.) Such unwrapping would also allow systems like the server-side "Filter out errors known to be caused by browser extensions" filter to act on this particular error.*

Alternatively (or in addition), we could teach the SDK to always ignore this particular error.

* Note that in order for the server-side filter to catch this error, the Extension context invalidated message would have to be added to the list of known extension errors, but that's easy enough to do.

[lobsterkatie]

Manual unwrapping (does no filtering, just creates a more reasonable event on which to act with filters or anything else):

Sentry.init({
  dsn: "YOUR DSN HERE",
  beforeSend: (event, hint) => {
    const capturedObj = hint.originalException;

    // handle CustomEvents which have real Errors buried inside them
    if (
      capturedObj instanceof CustomEvent &&
      capturedObj.detail &&
      capturedObj.detail.reason &&
      capturedObj.detail.reason instanceof Error
    ) {
      Sentry.withScope(scope => {
        // pull out the embedded Error object
        const buriedError = capturedObj.detail.reason;
        capturedObj.detail.reason = "<error object captured above>";

        // capture the rest of the CustomEvent's data as extra
        Sentry.setExtras({
          originalThrownObject: capturedObj
        });

        // create a new event out of the real Error, annotated with the other data
        Sentry.captureException(buriedError);
      });
      
      // don't send the original, badly-structured event
      return null;
    }

    return event;
  }
});

[esetnik]

@kamilogorek is there a best practice for filtering exceptions like this on the client side? We just had a single user visit our site and exhaust our entire quota due to the exception mentioned in #2210 (comment)

[kamilogorek]

@esetnik you can do this in the project settings, eg https://sentry.io/settings/sentry-test/projects/kamil-test/filters/data-filters/ This filtered events won't count toward the quota.

[esetnik]

@kamilogorek I have "Filter out errors known to be caused by browser extensions" already turned on and still exhausted my quota.

[kamilogorek]

@esetnik can you paste a link to at least one event that went through? I'll check what's wrong

[esetnik]

@kamilogorek sorry about that, I accidentally looked at the wrong project. It appears to be working. Again sorry for derailing the conversation on this issue.

[kamilogorek]

@esetnik no worries, glad it works