sentry-react-native

sentry-react-native copied to clipboard

Environment

What version are you running? Etc.

@sentry/[email protected] @sentry/[email protected] @sentry/[email protected] @sentry/[email protected] @sentry/[email protected]

Steps to Reproduce

1. I try to upload debug files using following command ion iOS ../node_modules/@sentry/cli/bin/sentry-cli debug-files upload "$INCLUDE_SOURCES_FLAG" "$DWARF_DSYM_FOLDER_PATH" --project XXX

2. I can see that the debug-files and source maps are uploaded under Sentry project settings.

3. I try to test following scenarios in my app

• Invoke Sentry.captureException() -> Sentry logs correctly point to the exact line number in the JS file ✅
• Enable enableCaptureFailedRequests: true & simulate a network error -> Works as expected, Sentry shows the network error logs ✅
• Invoke Sentry.captureMessage('Logging information for testing', 'warning') -> Sentry captures the log but says 'Source code was not found' ❓
• Invoke Sentry.nativeCrash() to simulate a native crash -> Sentry captures the error but says 'A required debug information file was missing'❓

Some of the logs are readable and only crashes and Sentry.captureMessage are having issues finding the correct symbols and debug files.

Expected Result

Native crashes and Sentry.captureMessage should map debug symbols and point to the exact error.

More information

Sourcemaps and debug files are uploaded in Sentry.

Hi, thanks for the message and screenshots, could you check how does the path in $DWARF_DSYM_FOLDER_PATH looks like? And check if the not uploaded dSYMs are in that path? My guess is that the XCode builds generated the dSYM to a different directory and that is why they were not uploaded.

Hi, thanks for the message and screenshots, could you check how does the path in $DWARF_DSYM_FOLDER_PATH looks like? And check if the not uploaded dSYMs are in that path? My guess is that the Xcode builds generated the dSYM to a different directory and that is why they were not uploaded.

I checked the DWARF_DSYM_FOLDER_PATH and it has the files in my local machine. Also I can see the debug files and source maps are uploaded and some of logs are processed correctly and pointing to the correct code of line. I also updated the description with more findings I had.

@krystofwoldrich would you have some other idea what could be causing the issue?

We've also tried it with the newer @sentry/[email protected], but that made no difference.

Hi, I've got a bit confused by the debug symbols. This looks like a bug of sentry-react-native. The attached stack trace to the message doesn't get symbolicated using the source maps.

The cause could be the RewriteFrames doesn't get executed for the threads stack trace but only exception stack trace https://develop.sentry.dev/sdk/event-payloads/threads/

@krystofwoldrich Do you have any updates on this issue?

@AlexanderEggers Besides what you can see in the issue, no updates.

@krystofwoldrich I'm mainly interested in https://github.com/getsentry/sentry-react-native/issues/3120 which sill forces us to use the workaround that is mentioned. You closed that issue in favor of this one.

@AlexanderEggers Thank you for the link to the other issue.

Reacting to the comment from there.

That case is creating a lot of events with the title which doesn't seem correct.

Could you share the current workaround title and the stack trace (source example if possible) and the expected title?

Could you share the current workaround title and the stack trace (source example if possible) and the expected title?

Hi, @krystofwoldrich. I ran into the stack track issue as well. Fortunately, switching from captureMessage to captureException was a reasonable workaround but the one downside is the display of the issues.

with captureMessage (preferred)

with captureException (works but suboptimal)

In some cases, the captureException displays in RED, which also makes them look more "urgent" than they really are.

If captureException supported the ability to display the same way as captureMessage, the workaround would be fine.

@Off2Race Thank you for the message, we will focus on fixing the captureMessage.

This https://github.com/getsentry/sentry-react-native/issues/2131 was the original reason to move the stack attached to a message from stacktrace to threads.

Currently threads are not used in JS, both in rewrite frames and in DebugIDs resolution. Therefore the frames from threads are not symbolicated.

The original issue was the message stack was missing on Android because the stacktrace field would be removed. That is not the case with exception field used by JS SDK today.

Moving the message stack to exception to unify with JS SDK will resolve both the rewrite frames issue and DebugIDs resolution. Although it's not in line with https://develop.sentry.dev/sdk/event-payloads/stacktrace/ I believe we should revert to what JS SDK is doing.

Hi @krystofwoldrich I am wondering if this fix was released? I am having exactly the same issue and I am on version 5.22.2.

I can confirm that changing captureMessage to captureException fixes the original issue but does not look too good

I have integrations: [captureConsoleIntegration({ levels: ['error'] })] on to capture console.error("Test error") as errors, but this also doesn't include the stack trace despite being an error. Obviously the workaround doesn't work in this case

@armata007 This will be released in version 6 of the SDK.

@melyux Could you open a new issue, as you mentioned this is not about captureMessage, we will need more information to investigate it.