UnhandledRejection - Non-Error promise rejection captured with value

It looks like the error might be coming from an embedded chromium app based on this matching error string in the CefSharp project. A Microsoft email checker might make sense.

2 Likes

Yes, even for us, it just says MSFT. Also, the browser version is very old

I have same errors genrated by MSFT.
But filtering “Non-Error promise rejection captured” is not a good idea.
We have same errors with more details that is related to our functionality and we need too capture and resolve them. ignoring them causes problems.

We’re starting to get a ton of these errors recently as well and it is crashing the server.

More details
Version of sentry:

"@sentry/react": "^6.2.3",
"@sentry/tracing": "^6.2.3",

User IP identified as “Microsoft Corporation (MSFT)” as well.

Any updates on this one?

In the next version - 6.9.0 (releasing as we speak), Dedupe integration is turned on by default, which should lower the impact of this issue tremendously.

1 Like

Just to second this, throwing a filter that broad onto the SDK is generally not a good idea. Instead, try to be more specific. This MSFT error which has lately cropped up for folks always has the “Object Not Found Matching Id” phrase in it, so I’d advise instead filtering on that instead of “Non-error promise rejection captured with keys,” which is just the SDK’s escape hatch for trying to provide at least some information when code rejects with something other than an instance of the Error class.

Ths issue is not only to filter the errors, but that it seems that Sentry is going into an infinite loop/endless recursion and generating a multitude of errors. I don’t mind ignoring one error, I can also filter them, but Sentry has to fix this mechanism that gets activated.

The behavior is exactly the same: Lots of sentry.event calls, followed by an exception at the end.

It’s not actually an infinite loop on our part - it’s just the SDK capturing a flood of the same error. (Each entry in the long list you see, in the Breadcrumbs section, corresponds to a separate instance of this error being captured by the SDK.) As Kamil says, now that the Dedupe integration is again on by default, even if you do see this error, you shouldn’t see it repeated over and over again the way you have been.

3 Likes

Same thing here! All the IPs coming from Microsoft. Microsoft always does problems…

We’re starting to get a ton of these errors recently as well and it is crashing the server.

How can I solve this problem?

Hey there,

a good first step is to update your SDK to the latest version. If you read the thread above you can see that the dedupe integration is now a default latest version of the browser SDK.

Otherwise, there are some great tips for filtering this in lobsterkatie’s post.

Hello there,

@kamilogorek , @NickMeis
Can you gentlemen confirm that the dudupe integration does indeed prevent the duplicate ‘non-Error promise rejection’ errors from occurring? I had a look at the dedupe implementation, and found that if an event payload does not contain a message property (line 66), the function returns without capturing the error as a duplicate. As far as I can see, all these ‘non-error promise’ rejection events do not contain message properties.

Hi there,

If you look at the _shouldDropEvent method, on line 43, you can see it calls and evaluates the return of _isSameMessageEvent as well as _isSameExceptionEvent in that order in order as part of evaluating if an event is a duplicate.

I can’t speak to all non-Error promise rejection events (you will see that we don’t recommend filtering this phrase outright) but I have seen good results with upgrading to 6.9.0 in resolving the high volume errors when they are related to the MSFT range of IPs.

Ah, thanks @NickMeis.

I’ll give it a go.

1 Like

Exactly as @NickMeis mentioned, it’ll be dropped by _isSameExceptionEvent clause.

1 Like

Same problem here, and I agree that ignoring errors that broadly is really not a good strategy, a real fix would be appreciated.

Hey there,

have you successfully upgraded your SDK to the latest version? If you are experiencing a high volume of these types of errors related to the range of IPs associated with MSFT, I would recommend that as a first step, the integration that is turned on by default in current versions of the SDK is available for earlier versions, but this solution is likely much quicker to implement.

I did update very recently yes, and we have the Dedupe plugin activated so we’re good on that front but we still don’t understand where this issue is coming from.

Did someone understand what’s the root cause of this issue?

All that we got, that this errors come from Microsoft ips, and they appear on different browsers. But what microsoft service is doing that and how to solve this issue?

If someone knows, it will be nice to hear the reason.

Hello! Wondering if anyone here has been able to overcome this particular Sentry error? I’ve updated to using v6.13.3, but am still getting this same error from a Microsoft IP address.

Hi, the error will still occur, however the number of these error events captured by Sentry should be a lot less as the Error deduplication feature is enabled by default in the more recent versions of Sentry.

I too would like to know how to go about solving this error as it’s been up in the air for a while.

I am getting the same error about 32 error per day. I would like to now how I fix that