[v6] Sourcemaps support in Crashlytics dashboard

[michaelgmcd]

I can make a feature request if this is unsupported, but our deployed application shows some pretty illegible stack traces. I've been able to generate sourcemaps following this SO answer. When including them in the app when deploying, it doesn't seem to have any effect on the stack (Crashlytics seems to ignore them). Is there any way to process these? Potentially some configuration of StackTrace.fromError (link) could achieve this?

Thanks for your awesome work!

Example stack trace:

[darkmantle]

+1

This would be far easier than having to load / search the bundle file every single time. Even that doesn't always work properly as it's hard to trace errors.

[mikehardy]

I can't search for it now, but look in react-native 0.60 for a PR from pvinis, I don't believe react-native supported it well until that PR landed. It should have relevant discussion as well

[stale]

Hello 👋, to help manage issues we automatically close stale issues.
This issue has been automatically marked as stale because it has not had activity for quite some time. Has this issue been fixed, or does it still require the community's attention?

This issue will be closed in 15 days if no further activity occurs.
Thank you for your contributions.

[michaelgmcd]

@mikehardy Seems promising. I guess we can wait until then: facebook/react-native#23691

[Salakar]

This should be much better now as that PR by @pvinis did land in RN 60 afaik. These will still be minified stack traces but now with more details such as function names etc.

Re: source mapping for JS this is still a limitation of Crashlytics but we are speaking to the Firebase team about it.

Will close this issue for now until we know more but feel free to continue the discussion.

[claudioviola]

@Salakar
Hey Mike
I didn't get what exactly mean "source mapping for JS this is still a limitation of Crashlytics"

In your article of 24th of April (here https://tinyurl.com/yyyp89cd) in the new feature list you are talked about "JavaScript stack traces are now automatically captured and visible on the Firebase Crashlytics console"

Is it possible to see the stack trace and understand where exactly the code fails?

Do I need to set something to build source maps in my react-native build command?

Thank you!

[mikehardy]

A separate Mike but I researched this recently and I'm not aware of a way to get Crashlytics to do source-mapping, though it will do the javascript stack trace (from the bundle) at least in v6

Here were my notes (note I am using Typescript as an extra layer for symbolication, and fastlane for builds, but hopefully this has inspiration):

as research for the final symbolication work (so we can take a crashlytics trace, have the javascript stack included in it, and be able to resolve that stack trace to the original typescript we need a few things:

react-native-firebase v6 (won't work in v5) which should be out in September
we need to either save the typescript maps or make sure we can reproduce builds exactly (https://www.typescriptlang.org/docs/handbook/compiler-options.html) and we need to either save the javascript maps or make sure we can reproduce them (https://stackoverflow.com/a/49487208/9910298)
we need a tool to process the crashlytics javascript stack back down to typescript (https://github.com/SoftwareMansion/stack-beautifier)

I think for support staff to be expected to reproduce a build isn't a great idea, so our fastlane script should be augmented to generate the right maps and dump them somewhere in source while tagging the build
then a tool can rely on a non-mapped stack along with a tag and resolve things

[claudioviola]

@mikehardy your idea could works nice but looks a bit complicated.
If I got your idea react-native-firebase v6 gives only javascript stack trace, so we should download the stack trace and then process it together with the source maps that we saved and pushed into the specific git tag of that deployment. After we can start to understanding the error.
Did I get correctly your solution?

At the moment subscription services like bugsnag could be soft solution to get the purpose... Without so many effort...

What do you think?
Thanks

[mikehardy]

Sure, sounds like bugsnag (if it provides symbolication) would work.

seems like you've got the underlying chain of requirements that need to be met anyway

I personally build tools pretty quickly so the one-off isn't a high cost for me vs the ongoing burden of "services I use" proliferation so I wouldn't want to add bugsnag to my stack just for this, but that's me.

[Salakar]

Still no news from Crashlytics folks but I'm going to bring it up again in person again with them at the Firebase Summit next week.

I originally suggested expanding on the existing Firebase Cloud Functions for Crashlytics events you can currently do and adding the ability there to read/update to the stack trace on new events.

https://firebase.google.com/docs/reference/functions/functions.crashlytics.IssueBuilder#onNew

If you could read the stack trace from the Issue instance that'd be half the battle

[mikehardy]

Interesting, I could definitely see that working (new issue triggers function that reads stack, symbolocates vs sourcemaps you have in firebase storage perhaps, then writes stack back).

[amadeu01]

@Salakar the links you posted are broken

Still no news from Crashlytics folks but I'm going to bring it up again in person again with them at the Firebase Summit next week.

I originally suggested expanding on the existing Firebase Cloud Functions for Crashlytics events you can currently do and adding the ability there to read/update to the stack trace on new events.

https://firebase.google.com/docs/reference/functions/functions.crashlytics.IssueBuilder#onNew

If you could read the stack trace from the Issue instance that'd be half the battle

[michaelgmcd]

@Salakar any update on this?

[tangnguyenv]

@Salakar any updates?

[tastafur]

Yes, i need use sourcemap too, if we don't use Sentry than if it supports it

[ghasemikasra39]

I am using "@react-native-firebase/crashlytics": "^7.1.0", is there the source map functionality?

[mikehardy]

Sourcemaps are a feature in your build chain. It will depend on how you build your bundle. Then it will depend on you storing the sourcemaps (or having reproducible builds so you can regenerate them). Then you will need to integrate a tool (like stack beautifier I think?) to decode them after you get them from crashlytics. Firebase Crashlytics itself, and react-native-firebase/crashlytics, do not support source map generation or decode out of the box.

A PR to update the crashlytics module documentation here with steps to generate and decode sourcemaps would likely help a lot of people though

[fbartho]

@mikehardy did Source mapping ever become a thing here? -- I ask, because Bugsnag has source mapping, but the project I'm getting involved with has Firebase Crashlytics integrated instead.

[mikehardy]

Alas no, or not yet anyway. I spoke with a crashlytics person and personally lobbied for the feature at Google io. Still manual decode for now. Check invertase blog though I did make some big improvements details there

[mikehardy]

From a separate discussion, note that Hermes requires a different symbolocation toolkit: https://reactnative.dev/docs/next/symbolication