Provide stack traces for unhandled promise rejections

[ospfranco]

Problem

For a very long time when a promise rejects without an attached handler we get this warning screen without a correct stack trace, only some internal calls to the RN internals.

If you navigate to the anon function pointed in the error message you can see it is the babel transpiled version of the promise:

Is there anyway to reverse this and get the original line number?

I would like to contribute getting proper stack traces shown to the developer, this would be a major improvement to the DX of RN. I however do not have any experience with the internals of RN, so I'm dumping the info I have here, with the hopes of also getting some guidance from the core contributors to see if this can be improved.

Info

From what I've managed to gather and understand, currently, RN uses a Promise polyfill (why? JSC limitation). Apparently also JSC does not expose what is called HostPromiseRejectionTracker which would actually allow to get the correct traces. This info was provided in this thread on twitter by the folks at expo.

Now that RN is shipping with hermes by default we could 1. make sure that Hermes is exposing HostPromiseRejectionTracker and 2. check if RN is running on JSC or Hermes and if Hermes is used do not use the polyfill. This should allow us to get the proper stack traces.

I would gladly partake in this task if someone could guide me a bit in the internals of Hermes/RN.

[a7medev]

I believe Hermes already provided unhandled rejection tracking through HermesInternal.enablePromiseRejectionTracker and currently ships with optimized Promise (not sure if it's just the same polyfill but converted to bytecode though), you can check if Hermes is providing its own Promise or not through HermesInternal.hasPromise.

Here's how we use it to capture unhandled promise rejections in React Native: https://github.com/Instabug/Instabug-React-Native/blob/master/src/utils/UnhandledRejectionTracking.ts

[ospfranco]

Just took a look, ran the code, but it looks like the stack trace is the same. So I guess it is the same polyfill?

[a7medev]

@ospfranco Wouldn't symbolication (through source maps or on-device in development) help?

For release builds, you can use npx metro-symbolicate, and in development you can just use react-native/Libraries/Core/Devtools/symbolicateStackTrace at runtime. You can check Sentry's implemention for debug symbolication here:

https://github.com/getsentry/sentry-react-native/blob/main/src/js/integrations/debugsymbolicator.ts

[ospfranco]

I got it working! this is awesome, thanks a lot @a7medev!

[a7medev]

@ospfranco Perfect! Happy to know it helped.
I think we need to integrate that into React Native then, it's weird that all of these are just React Native internals but still they aren't integrated into unhandled promise rejections 🤷‍♂️

[ospfranco]

yeah, I will create a PR later!

[nandorojo]

Absolutely huge pain point for me that I deal with daily. I rarely get useful traces to the cause of an error. It gets even worse for npm packages where it often won’t mention the package.

Super excited for improvements here.

[ospfranco]

Managed to get this working and will hopefully be merged soon. Closing this discussion.

facebook/react-native#40914