search

getsentry / sentry-react-native

Official Sentry SDK for React Native
https://sentry.io
MIT License
1.57k stars 337 forks source link

getSentryExpoConfig(5.26.0) no longer unobfuscates stack traces with source maps #3967

Closed navignaw closed 2 months ago

navignaw commented 3 months ago

OS:

Platform:

SDK:

SDK version: 5.26.0

react-native version: 0.73.8

Are you using Expo?

Are you using sentry.io or on-premise?

Configuration:

Same as recommended in the guide: https://docs.sentry.io/platforms/react-native/sourcemaps/uploading/expo/

I have the following issue:

When building an Expo app with EAS build and the getSentryExpoConfig function with the annotateReactComponents set to true, stack traces no longer appear to be unobfuscated. EDIT: I'm also seeing no stack traces at all when this is set to false.

I suspect that this is due to the code conditionally running either withSentryFramesCollapsed or withSentryBabelTransformer, but the latter function is missing some logic for the source maps.

Steps to reproduce:

Actual result:

The stack trace is still obfuscated:

at anonymous(/data/user/0/com.my.app/files/.expo-internal/bundle-09ffe111-2624-4bbe-b654-7e168c002adb.js:1:2719482)
  at safeCallback(/data/user/0/com.my.app/files/.expo-internal/bundle-09ffe111-2624-4bbe-b654-7e168c002adb.js:1:3153014)
  at withScope(/data/user/0/com.my.app/files/.expo-internal/bundle-09ffe111-2624-4bbe-b654-7e168c002adb.js:1:2773796)
  at withScope(/data/user/0/com.my.app/files/.expo-internal/bundle-09ffe111-2624-4bbe-b654-7e168c002adb.js:1:3152992)
  at anonymous(/data/user/0/com.my.app/files/.expo-internal/bundle-09ffe111-2624-4bbe-b654-7e168c002adb.js:1:2719389)
  at ?anon_0_(/data/user/0/com.my.app/files/.expo-internal/bundle-09ffe111-2624-4bbe-b654-7e168c002adb.js:1:3561878)

Expected result:

The stack trace is unminified

navignaw commented 3 months ago

Sorry, I'm no longer actually sure if annotateReactComponents is the cause, or if this was just a regression in 5.26.0. Even after setting it to false, I was still unable to see unminified stack traces / source maps.

kahest commented 3 months ago

@navignaw thanks for the report and the follow-up. Would you be able to try and reproduce this with a previous version of @sentry/react-native?

krystofwoldrich commented 2 months ago

Hi @navignaw, thank you for the message,

could you share a code snippet of how are you testing this?

For example, are you using Sentry.captureException(new Error('My error'))?

Does it happen in debug or release builds? (I expect release as you mention when building in EAS)

Can you check your EAS build logs for the source maps upload? When you search for sentry in the logs, you should be able to see what files were uploaded to Sentry. On Sentry side when you open your project settings you should see the source maps uploaded.

navignaw commented 2 months ago

Hi @krystofwoldrich, after some investigation I believe I've narrowed down the problem. It happens in release builds only.

I can see that the source map is in fact uploaded correctly in Sentry project settings.

The stack trace is only obfuscated with calls to Sentry.captureMessage. It seems to work fine for actual exceptions that are raised in 3rd-party libraries. I've also noticed that there is a difference in the path to the errors.

For example, here is a stack trace for an error that is correctly unobfuscated:

LaunchDarklyTimeoutError: identify timed out after 5 seconds.
  at construct(native)
  at apply(native)
  at _construct(/Users/expo/workingdir/build/node_modules/@babel/runtime/helpers/construct.js:16:26)
  at Wrapper(/Users/expo/workingdir/build/node_modules/@babel/runtime/helpers/wrapNativeSuper.js:17:23)
  at construct(native)
  at _createSuperInternal(/Users/expo/workingdir/build/node_modules/@launchdarkly/js-sdk-common/dist/errors.js:4:1)
  at call(native)
  at LDTimeoutError(/Users/expo/workingdir/build/node_modules/@launchdarkly/js-sdk-common/dist/errors.js:46:9)
  at anonymous(/Users/expo/workingdir/build/node_modules/@launchdarkly/js-sdk-common/dist/utils/timedPromise.js:13:43)
  at apply(native)
  at anonymous(/Users/expo/workingdir/build/node_modules/react-native/Libraries/Core/Timers/JSTimers.js:213:23)
  at _callTimer(/Users/expo/workingdir/build/node_modules/react-native/Libraries/Core/Timers/JSTimers.js:111:15)
  at callTimers(/Users/expo/workingdir/build/node_modules/react-native/Libraries/Core/Timers/JSTimers.js:359:17)
  at apply(native)
  at __callFunction(/Users/expo/workingdir/build/node_modules/react-native/Libraries/BatchedBridge/MessageQueue.js:433:34)
  at anonymous(/Users/expo/workingdir/build/node_modules/react-native/Libraries/BatchedBridge/MessageQueue.js:113:26)
  at __guard(/Users/expo/workingdir/build/node_modules/react-native/Libraries/BatchedBridge/MessageQueue.js:368:11)
  at callFunctionReturnFlushedQueue(/Users/expo/workingdir/build/node_modules/react-native/Libraries/BatchedBridge/MessageQueue.js:112:17)

But here is a stack trace for an error logged with Sentry.captureMessage that isn't unobfuscated:

 at anonymous(/var/mobile/Containers/Data/Application/<redacted-uuid>/Library/Application Support/.expo-internal/bundle-<redacted-id>.jsbundle:1:2710007)
  at safeCallback(/var/mobile/Containers/Data/Application/<redacted-uuid>/Library/Application Support/.expo-internal/bundle-<redacted-id>.jsbundle:1:3143544)
  at withScope(/var/mobile/Containers/Data/Application/<redacted-uuid>/Library/Application Support/.expo-internal/bundle-<redacted-id>.jsbundle:1:2764321)
  at withScope(/var/mobile/Containers/Data/Application/<redacted-uuid>/Library/Application Support/.expo-internal/bundle-<redacted-id>.jsbundle:1:3143522)
  at anonymous(/var/mobile/Containers/Data/Application/<redacted-uuid>/Library/Application Support/.expo-internal/bundle-<redacted-id>.jsbundle:1:2709914)
  at ?anon_0_(/var/mobile/Containers/Data/Application/<redacted-uuid>/Library/Application Support/.expo-internal/bundle-<redacted-id>.jsbundle:1:3553081)
  at throw(native)
  at asyncGeneratorStep(/var/mobile/Containers/Data/Application/<redacted-uuid>/Library/Application Support/.expo-internal/bundle-<redacted-id>.jsbundle:1:657929)
  at _throw(/var/mobile/Containers/Data/Application/<redacted-uuid>/Library/Application Support/.expo-internal/bundle-<redacted-id>.jsbundle:1:658232)
  at tryCallOne(/var/mobile/Containers/Data/Application/<redacted-uuid>/Library/Application Support/.expo-internal/bundle-<redacted-id>.jsbundle:1:221925)
  ...

Notably the first is a third-party library in node_modules, while the second is in our own application bundle code.

Let me know if you'd like me to DM you links to the issues (I'd like to avoid sharing them publicly)

Tadimsky commented 2 months ago

I am seeing the same thing - and without using annotateReactComponents.

The callstack shows as this when using a captureMessage

Image

krystofwoldrich commented 2 months ago

@navignaw Thank you for the details. The issue is caused by the placement of the stack trace in the message event.

We fixed this for the next major version RN SDK v6, and now brought it for v5 as well.