React Natiive stack trace not app showing our code


#1

I’ve set up Sentry to work with my React Native project.

The .jsbunde.map is uploaded against the right version/dist used by the app and can see it in the UI.

When I force an error by using throw in the app, the error shows up. However, it only shows the source for Sentry JS code handling the error. I don’t see any of our app code. The last line in stack trace is app:///[native code] in value.

Any ideas why it’s not showing the code?


#2

Hey,

So there is a known bug in react-native (more, in metro the bundler used by react-native) which causes source maps generated to be broken.
Here is the issue in react-native https://github.com/facebook/react-native/issues/6946#issuecomment-408411557

Besides that app:///[native code] indicates that the last frame of the stack trace was executed in native, I am not sure but are you using our react-native SDK https://github.com/getsentry/react-native-sentry ?
The SDK is also able to pick up both Javascript and native crashes.


#3

Ah great, I hope this gets fixed soon.

Yes we are using the Sentry SDK and hooked up both native and JS crashes. We are using AppCenter to generate the bundle and maps. With this in mind should the app:///[native code] show something different? The Native symbols are uploaded and linked to the version.

The code used for this error is throw "error" on the JS side.

BTW seeing this with iOS - the bug report above seems to be related to Android only.


#4

So lately we also saw this popping up for iOS as well but we weren’t able to reliably reproduce it :slightly_frowning_face:


#5

If it helps I’m bundling into the release with AppCenter cli, and is the same files uploaded to CodePush. I update the Sentry map files in script using the upload-source maps on Sentry cli.

The version is matched in the app using Sentry.setVersion. I’m using a different version string than the <package name>-<version> to separate ios and android releases (as they use same package/bundle name but unsynchronised version/dist numbering. I get the CodePush dist number from the CodePush description field of the meta to marry everything up. This is because using the documented CodePush approach doesn’t work for us (label changes when moving between staging and production).


#6

Still the same issue, identifying a CodePush release with its version number is a very bad idea since it changes during CodePush promotion from staging to production environment. The release hash (available from CodePush CLI and into the app) should be used instead.


#7

Yeah that’s why we don’t use it, I match on build number not CodePush version.