Raven should treat polyfilled promise rejections as close to the native as possible

Do you want to request a feature or report a bug? feature

What is the current behavior? the native promises are reported with mechanism of type onunhandledrejection (or, in previous versions: extra.unhandledPromiseRejection: true) but not all unhandled promise rejections are captured with this.

There are polyfilled promises. Some of them support some way of unhandled promise rejection capturing.

I will use zloirock/core-js as example for 2 reasons: I use it day to day and because of being dependency babel-polyfill which is widely used.

There are others but I didn’t do any more research on what’s on top at the moment.

What is the expected behavior? It’s clear that it’s the polyfill what should mimic the native promise behavior as much as possible. But they don’t always do that. At least current core-js (v2) does something else: it uses console.error in the browser. Latest stable version (v2.5.7) of core-js does it like this: https://github.com/zloirock/core-js/blob/v2.5.7/modules/es6.promise.js#L110

It will improve soon (it will emit the unhandledrejection for browsers that support custom events), but it’s now in beta. And it will get adopted even later than released as stable. https://github.com/zloirock/core-js/blob/028dd85d6c0eed606ce607057b7744eb7aa89c24/packages/core-js/modules/es.promise.js#L117-L128

The problem is that it currently is, and in certain circumstances it will continue to fall back to something like:

console.error(<Some string determining that it is unhandled promise rejection>, reason);

The problem I see that this is only captured by Raven if console plugin is used (by default raven only instruments console for breadcrumbs afaik) and it’s visible in Sentry in a different way. Most importantly: with an incorrect stack trace (the trace is mostly about what happens in the polyfill promise, not that is there in the actual error, if it’s error what’s promise rejection reason)

Sentry uses traces to decide in which issue should the event be categorised (I’m omitting the intentional fingerprints on purpose in here) but if there’s no trace and 1st argument is always the same Sentry ends up capturing many errors in the same issue which makes the investigation harder (especially since it’s not possible to manually split issues)

I suggest Raven should try to understand the unhandled rejections of commonly used promise polyfills.

The naive solution of checking if there are 2 arguments and if the first is a known string may not be enough

[jrencz]

@kamilogorek was this included in sentry browser or do I need to find a way to add it back on my side If I want it back?

[kamilogorek]

Hello, thanks for reporting the issue.

We are in the process of working on the next major release of our SDK. Because of that, we had to put working on the current version (except major or security bugs) on hold. We’ll try to get back to all the reports as soon as possible, so please be patient.

Thanks for your understanding, Cheers!