Very uninformative onunhandledrejection errors when rejecting with Event

[rchl]

• 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.6.2

Description

Errors captured through onunhandledrejection mechanism never really provide any useful information that would help in figuring out the problem.

In my app, I have thousands (17K as of now for one of them, after few months) of UnhandledRejection errors. All info that those events provide is just a an error text like UnhandledRejection: "CustomEvent" (note that with latest version of Sentry it became a little bit more informative with UnhandledRejection: Non-Error promise rejection captured with keys: isTrusted text). There is no stack nor extra context and those errors happen on routes and paths that work perfectly for me and everyone I know so I'm unable figure out how to address them.

Now, I assume, that the problem is only with unhandled promise rejections that reject with non-Error type like primitive values (string, null, etc.) or (like in this case) an Event object. While I don't see how to improve cases with primitive values, I think for event objects, more data could be logged.

It seems the UnhandledRejection: Non-Error promise rejection captured with keys: isTrusted message comes from the fact that isTrusted is the only iterable key on the event object (try console.log(Object.keys(new CustomEvent('test')))). But event objects have more useful (non-iterable) keys that could provide more information about the error. Namely I'm thinking about detail and type properties. I think those could help identifying from which code event is coming from.

So I'm suggesting to add some custom code (if there isn't already) for handling that special case (unhandledrejection with event object) better.

Some example events:
https://sentry.io/share/issue/4d294f75e9704103b7c3b49e62b6e278/
https://sentry.io/share/issue/c36904ab4c224fbda6f1afff63c106ee/
(these are minimal, sharable versions but full events don't really provide any other meaningful information either.)

[rchl]

For the time being, I've added a beforeSend hook like:

beforeSend: function(event, hint) {
    if (hint && hint.originalException instanceof Event) {
        event.extra.isTrusted = hint.originalException.isTrusted;
        event.extra.detail = hint.originalException.detail;
        event.extra.type = hint.originalException.type;
    }

    return event;
},

BTW. detail is a property of CustomEvent, not Event, but for my purposes I don't care.

[ajhool]

I'm experiencing this, too, and I think that Sentry needs to handle non-Error types properly, rather than treating them like an error.

I'm still working through the problem and I tried adding this code to wrap objects in an Error type, but this didn't fix the problem:

  const wrappedError = (err instanceof Error || typeof err === 'string') ? err : new Error(JSON.stringify(err));
  Sentry.captureException(wrappedError);

Next, I'm going to try using Sentry.captureMessage if the instance type is not an Error, but a lot of third party libraries throw non-Error types that should be treated as Errors in Sentry IMO

I would actually disagree with the title of this issue -- I don't think that Sentry is being uninformative, I think it's actually informing developers that Sentry doesn't properly handle some types of common javascript errors (ie. thrown objects that aren't of instance type: Error). I see this as being an actual bug in Sentry, because a thrown Object in javascript is still an Exception/Error, even if the thrown object is not of Error type IMO. I'm not sure where the javascript community would stand on this, admittedly (https://stackoverflow.com/questions/9156176/what-is-the-difference-between-throw-new-error-and-throw-someobject)

[rchl]

What would it achieve to wrap non-error with Error? Are you expecting to get stack trace as a result? I I'm not sure that would work with native unhandledrejection handler. If it would provide meaningful stacktrace then I would agree with you that it would be worth doing. Otherwise I don't really see the point.

[ajhool]

Wrapping a non-Error in Error was just to get the correct format for compatibility and also typing.

I have experienced several third party libraries that throw objects that have some information about the error but the nature of the error is . It is somewhere between an event and an error.

For instance, Google Analytics throws this object:

 {
    details: Not a valid origin for the client: https://mywebsite.com has not been whitelisted for client ID myid.apps.googleusercontent.com. Please go to https://console.developers.google.com/ and whitelist this origin for your project's client ID.,
     error: idpiframe_initialization_failed
}

Which is an error that I'd like to know about in Sentry and it makes it all of the way to Sentry's captureException, but google throws it as an object instead of an Error (as far as I can tell), so Sentry doesn't handle it in the a way that is intuitive to me.

Javascript users should throw Errors, but the language allows them to throw plain objects, and sometimes they do. Those objects often contain error information that is helpful for debugging (the google example tells me everything I need to know) even without a stacktrace

A dynamic version of @rchl 's strategy would make sense to me -- iterate through the object keys and attach them to event.extra

[rchl]

With unhandledrejection errors, it's not really possible to get meaningful stack strace (I've just tried - stack starts at unhandledrejection handler). And if you don't have stack trace, the message is all that can be used for grouping (I guess). So you would probably get a lot of separate issues in Sentry because all stringified objects would differ slightly (for example with the URL). So I'm not sure that would be the best approach.

But your usecase is already handled in latest Sentry version. You get extra.__stringified__ field that contains stringified object. It doesn't work with Event types because those don't have any meaningful toJSON/toString implementation though... But it should work fine with plain objects.

[Neaox]

Sometimes the object/event has a message key, I would much prefer it if that were used for the wrapped exception message...

[cynicaloptimist]

I'm currently receiving thousands of instances of this error from a relatively small number of users. Since I'm just testing out Sentry right now with a free plan, there's no way to filter them out. Spike Protection also does not seem to react to this issue.

[ajhool]

@cynicaloptimist I hope this isn't pointing out the obvious, but a quick patch is just to filter them out on your client, assuming the errors are all the same type. In my case, it was a warning from social login buttons when I was in dev mode.

[cynicaloptimist]

@ajhool yep, I'll probably do that if the issue persists and I decide to keep using Sentry. I thought it might be helpful to report the impact to this Issue discussion.

[mogelbrod]

We're getting the same kind of UnhandledRejections reported in Sentry, even for errors that we know was instanceof Error when the error was thrown. We're adding the enumerable error properties to the extra object, and thus can verify that the errors which Sentry don't detect as being proper Errors in fact are that.

 beforeSend(event, hint) {
  event.extra = event.extra || {}

  if (hint.originalException != null) {
    // Assign enumerable error properties to extras
    try {
      const keys = Object.keys(hint.originalException)
      if (keys.length) {
        event.extra.errorProperties = {}
        keys.forEach(key => {
          event.extra.errorProperties[key] = hint.originalException[key]
        })
      }
    } catch (error) {
      console.warn('[sentry] Failed to assign enumerable error properties to extras', error)
    }
  }

  return event
}

These errors are displayed like this in the Sentry UI:

The extras for these errors look like the following:

{
  '__serialized__': '**non-serializable**',
  'errorProperties': {
    description: '....',
    stack: '....',
    // additional properties set on error
  }

As you can see the Sentry serialization (__serialized__) appears to fail, while our own beforeSend() code is successful in serializing the error properties.

[kamilogorek]

I scheduled better Event/CustomEvent handling work for the next week. Will keep everyone posted on this one.

@mogelbrod is there a way you can provide a repro-case for this? We never had an issue with TraceKit incorrectly detecting Error instances.

As for your additional enumerables, we have an integration for this – https://docs.sentry.io/platforms/javascript/#extraerrordata

import * as Sentry from '@sentry/browser';
import { ExtraErrorData } from '@sentry/integrations';

Sentry.init({
  integrations: [new Integrations.ExtraErrorData()]
});

is basically equivalent of your beforeSend snippet.

[mogelbrod]

Most of the Non-Error promise rejection captured errors are reported from IE11, so I'm guessing it's another case of IE not behaving. In 3 out of 4 cases we've added properties to the error before throwing, which I initially suspected might cause IE to no longer consider it an instanceof Error anymore. Trying a transpiled version of the below code in IE11 still worked though, so I'm not sure what's breaking it.

import "core-js/modules/es.object.assign";
import { init } from "@sentry/browser";

init({
  dsn: "https://replace@sentry.io/me"
});

setTimeout(() => {
  const err = new Error("hello");
  err.customProp = true;
  throw err;
}, 10);

Here are some example issues from our production environment:

1. ... with keys: [object has no keys] for EncodingError (Safari/Chrome)
2. ... with keys: column, line, sourceURL for Error (Safari)
3. ...with keys: body, description, errorType, header for Error (IE11)
4. ...with keys: description, number, stack for Error (IE11)
5. ...with keys: body, description, duringTrackedOutcome for superagent Error (IE11)

[karol-majewski]

@mogelbrod for us it's almost exclusively Chrome, not IE.

98% out of approximately 40k reports.

[antoinerousseau]

I'm having the same issue, but for various browsers/visitors

In additional data, I have the error as a __serialized__ object, e.g.:

 {
  message: Failed to fetch, 
  name: TypeError, 
  stack: TypeError: Failed to fetch
}

or

{
  message: annulé, 
  name: TypeError, 
  stack: [undefined]
}

or others

Using Sentry 5.6.3

[ajhool]

@karol-majewski Google Chrome plugins were triggering some of these events for me. Adblocker was triggering a social login complaint that wouldn't have been triggered in IE. I am also seeing this behavior from mulitple devices and browsers

[karol-majewski]

@ajhool Thanks for the update. As for devices, there is another anomaly.

This error only happens on two devices:

1. HTC D160LVWPP
2. Generic smartphone (that's what Sentry calls it)

What's even more interesting, the os section is telling us 90% of occurrences are happening on... macOS. Either those errors are not grouped correctly, or there is something shady going on.

[alexlouden]

We're also seeing a lot of these - over 35k UnhandledRejection: "CustomEvent", mostly in the last week. I've added the ExtraErrorData and updated our SDK, will see if we can get some more details of where they're coming from!

[karol-majewski]

I've added the ExtraErrorData and updated our SDK, will see if we can get some more details of where they're coming from!

We tried that but to no avail. Additional data look like that:

[kamilogorek]

I just rolled out 5.7.0-beta. Would appreciate testing it out via

npm install @sentry/browser@5.7.0-beta.0

It improves events serialization and unifies some differences between reject/onerror/manual error handling. It also removes any dependencies that were necessary for IE10/11, including Promises, so we have to make sure it's working correctly.

Any feedback appreciated! :)

[karol-majewski]

@kamilogorek I tried running it but was unable to get the project to build because of type definition errors.

The domain module is declared in both @sentry/hub/dist/hub.d.ts and in @sentry/browser/node_modules/@sentry/hub/dist/hub.d.ts, which is a no-go for TypeScript:

declare module 'domain' {
    let active: Domain;
    /**
     * Extension for domain interface
     */
    interface Domain {
        __SENTRY__?: Carrier;
    }
}

Console output:

I'm also using:

• "@sentry/integrations": "^5.6.1"
• "@sentry/node": "^5.6.2"

[kamilogorek]

@karol-majewski it looks like the versions are out of sync. What's your current setup? Are you talking about the new beta version? (as you listed 5.6)

[karol-majewski]

@kamilogorek Updating all the accompanying packages seems to have helped, thank you.

[fa93hws]

Hi, would this issue be related to #424 that brought by a third party promise library even thought it's the legacy SDK? https://docs.sentry.io/clients/javascript/usage/#raven-js-promises

[ambreelmee]

@brandonburkett No I still have the same issue popping almost every second for some users until we eat all our quota and hope that next month it will be solved ... 😥

[darthzeran]

Could it be that the Chrome violations are being interpreted as something that requires an error to be thrown?
We got the OP's log in sentry 200 times today , and I noticed them in the console logs for the first time.

reference link: https://stackoverflow.com/questions/41218507/violation-long-running-javascript-task-took-xx-ms/41218580

[esetnik]

I have the same error happening frequently in our sentry project.

CustomEvent: Non-Error promise rejection captured with keys: currentTarget, detail, isTrusted, target
--

Traced it to the same unknown chrome extension mentioned above:

message: Extension context invalidated., 
name: Error, 
stack: 
Error: Extension context invalidated.
    at Object._updateMetadata (chrome-extension://haldlgldplgnggkjaafhelgiaglafanh/admin.js:9:168287)
    at chrome-extension://haldlgldplgnggkjaafhelgiaglafanh/admin.js:9:168105
    at c (chrome-extension://haldlgldplgnggkjaafhelgiaglafanh/admin.js:9:140858)
    at E._settlePromiseFromHandler (chrome-extension://haldlgldplgnggkjaafhelgiaglafanh/admin.js:9:113655)
    at E._settlePromiseAt (chrome-extension://haldlgldplgnggkjaafhelgiaglafanh/admin.js:9:114928)
    at E._settlePromises (chrome-extension://haldlgldplgnggkjaafhelgiaglafanh/admin.js:9:116773)
    at u._drainQueue (chrome-extension://haldlgldplgnggkjaafhelgiaglafanh/admin.js:9:74164)
    at u._drainQueues (chrome-extension://haldlgldplgnggkjaafhelgiaglafanh/admin.js:9:74225)
    at drainQueues (chrome-extension://haldlgldplgnggkjaafhelgiaglafanh/admin.js:9:72536)

[kamilogorek]

@esetnik this one is tracked here #2380

[kamilogorek]

As this thread got really large. First, please update the version of the SDK to the newest one, and then please open a new issue detailing what, where and how it is happening, so we can start to fix them one by one. Thanks!

[ilanbm]

I've got 75K events from this chrome extension and it ate my quota

As this thread got really large. First, please update the version of the SDK to the newest one, and then please open a new issue detailing what, where and how it is happening, so we can start to fix them one by one. Thanks!

@kamilogorek should a new issue be opened?

[kamilogorek]

@ilanbm can you provide a link to the event from your screenshot? I'd like to take a closer look at it.

[ilanbm]

Well I don't have a link to it anymore, I was directed by your support to 'inbound filtering' section to check 'Filter out errors known to be caused by browser extensions'
It solved the issue.

I haven't noticed that section and solution nor seen it anywhere on documentation or any discussion.

[cshouts-tasc]

@Jun711 @karol-majewski I found the offending extension. It's called GoGuardian https://www.goguardian.com/ and the extension is installed via their own installer rather than through the Chrome Web Store.

[brandonburkett]

I wonder if these "installed outside of web store" extensions can also be filtered out with the Filter out errors known to be caused by browser extensions checkbox.

[JustFly1984]

@brandonburkett
After enabling proper CSP headers we are getting many errors generated by plugins in console due to limit in injection/execution of JS CSS and etc, but never seen any in Sentry logs.

BTW real errors generated by misconfiguring CSP correctly goes to Sentry logs

[brandonburkett]

@JustFly1984 Got it. Unfortunately my CSP are pretty limited do to adsense. We get quite a few chrome extension sentry logs that usually eats our quota in about a week :(

We are also filtering via configuration beforeSend -> event.extra.__serialized__.detail.reason.message === 'Extension context invalidated.' but still some gets through.

[JustFly1984]

@brandonburkett we had used reportOnly CSP with strict rules to gather valid and invalid CSP rules, to make CSP as strict as possible before applying it to production. This way we can prevent malicious browser extensions from messing with our code.

[dmarman]

Same issue today with this extension & version 5.15.0 upgraded to 5.15.5: https://sentry.io/share/issue/3461d17193c64e1d980cd6d41a66ba23/

[kiruh]

Version: 5.15.5

I have tried to reduce an error noise by setting ignoreErrors and blacklistUrls as described here https://docs.sentry.io/platforms/javascript/#decluttering-sentry

Sentry.init({
    dsn,
    ignoreErrors: [
      // Random plugins/extensions
      'top.GLOBALS',
      // See: http://blog.errorception.com/2012/03/tale-of-unfindable-js-error.html
      'originalCreateNotification',
      'canvas.contentDocument',
      'MyApp_RemoveAllHighlights',
      'http://tt.epicplay.com',
      'Can\'t find variable: ZiteReader',
      'jigsaw is not defined',
      'ComboSearch is not defined',
      'http://loading.retry.widdit.com/',
      'atomicFindClose',
      // Facebook borked
      'fb_xd_fragment',
      // ISP "optimizing" proxy - `Cache-Control: no-transform` seems to
      // reduce this. (thanks @acdha)
      // See http://stackoverflow.com/questions/4113268
      'bmi_SafeAddOnload',
      'EBCallBackMessageReceived',
      // See http://toolbar.conduit.com/Developer/HtmlAndGadget/Methods/JSInjection.aspx
      'conduitPage'
    ],
    blacklistUrls: [
      // Facebook flakiness
      /graph\.facebook\.com/i,
      // Facebook blocked
      /connect\.facebook\.net\/en_US\/all\.js/i,
      // Woopra flakiness
      /eatdifferent\.com\.woopra-ns\.com/i,
      /static\.woopra\.com\/js\/woopra\.js/i,
      // Chrome extensions
      /extensions\//i,
      /^chrome:\/\//i,
      // Other plugins
      /127\.0\.0\.1:4001\/isrunning/i,  // Cacaoweb
      /webappstoolbarba\.texthelp\.com\//i,
      /metrics\.itunes\.apple\.com\.edgesuite\.net\//i
    ]
  });

Yet I still receive those errors.

Is there anything I can do? Because it's eating my quota.

[kamilogorek]

@kiruh it should be easily filtered with per-project setting:

[OliverJAsh]

Version 5.15.5

Setting to filter out browser extension errors is enabled:

We're still receiving loads of these errors:

Non-Error promise rejection captured with keys: currentTarget, detail, isTrusted, target

Breadcrumbs:

__serialized__ in additional data (with the ExtraErrorData integration enabled):

{
currentTarget: [object Window], 
detail: None, 
isTrusted: [Circular ~], 
target: [object Window], 
type: unhandledrejection
}

If there was a way to reproduce this error then I would try to dig in to the code that was supposed to fix this (added in #2429), but it seems nobody has a way to reproduce this. 😢

Note that these errors are coming from users running even the most recent versions of our app, long after we upgraded Sentry to 5.15.5.

Maybe #2429 does not help because detail is None.

[FlyOrBoom]

I believe the haldlgldplgnggkjaafhelgiaglafanh ID is that of an unlisted extension called "GoGuardian Beacon". See the screenshot in step 12 of Beacon's installation manual. GoGuardian is a company that makes software tracking students. They may have cloned the HTML Content Blocker extension, rebranding & unlisting their copy for commercial use, which is why HTML Content Blocker's fingerprint is present instead of Beacon's.

A student on a device with GoGuardian Beacon (force-)installed and using Sentry probably caused the error.

[sokratis-valavanis-pph]

Hello @OliverJAsh, we have the same uninformative logs as your case at the serialized section
{ currentTarget: [object Window], detail: None, isTrusted: [Circular ~], target: [object Window], type: unhandledrejection }
. Have you found a solution?

[fyelci]

Hi,
We have similar error for only safari users on Mac. Is there a solution for this?
CustomEvent: Non-Error promise rejection captured with keys: currentTarget, detail, isTrusted, target

[jacprada]

@fyelci did you happen to find out more about it? Experiencing the same issue here, only Safari users on Mac.

[fyelci]

@jacprada no I couldn't find a solution for this. Just ignored that and didn't happen again.

[ndvbd]

Very long thread. Any solution here?

[kamilogorek]

It's all use-case specific, so you need to trace the issue in your project using __serialized__ field in the Sentry event.

[Dinesh101041]

We are facing the same issue with our organisation , one issue as Unhandled PromiseRejectionEvent and one as Unhandled Event there is no traces also it logs more than 3K times in a day , we are facing this in sentry browser 4.6.6

Attached the issue : https://sentry.io/share/issue/3a30791dc94c436292f9265fcd178ae8/

Attached the devices image as well

can any one help me with how to solve this