expo / sentry-expo

MIT License
202 stars 83 forks source link

Expo sentry package not detecting native crash in production #362

Closed muninderkaur06 closed 4 months ago

muninderkaur06 commented 1 year ago

Summary

Expected behaviour - The package should detect all kinds of crash.

Actual behavior - This package is only detecting errors & exceptions in the Sentry dashboard.

Following is my code snippet :

try {
    return (
    <RootSiblingParent>
      <StorageProvider>
        <SafeAreaProvider>
          <AppearanceProvider>
            <ThemeProvider>
              <PostProvider>
                <ModalProvider>
                  <UserEventProvider>
                    <StateContext>
                      <AppNavigator />
                    </StateContext>
                  </UserEventProvider>
                </ModalProvider>
              </PostProvider>
            </ThemeProvider>
          </AppearanceProvider>
        </SafeAreaProvider>
        </StorageProvider>
      </RootSiblingParent>
    );
  } catch (error) {
    Sentry.Native.captureException(error);
  }

I even tried using Sentry.Native.wrap(App), but in every case errors & exceptions are only getting detected.

I went through this old link which says Sentry does not support detecting of native crashes. Has it not been fixed yet? : https://forum.sentry.io/t/expo-production-crashes-not-reported-in-sentry/7119

Managed or bare workflow? If you have ios/ or android/ directories in your project, the answer is bare!

managed

What platform(s) does this occur on?

Android, iOS

SDK Version (managed workflow only)

^49.0.0

Environment

expo-env-info 1.0.5 environment info: System: OS: Windows 10 10.0.22621 Binaries: Node: 16.15.0 - C:\Program Files\nodejs\node.EXE Yarn: 1.22.19 - ~\LexiconTesting\lexicon\frontend\node_modules.bin\yarn.CMD npm: 8.5.5 - C:\Program Files\nodejs\npm.CMD npmPackages: expo: ^49.0.0 => 49.0.3 react: ^18.2.0 => 18.2.0 react-dom: 18.2.0 => 18.2.0 react-native: 0.72.3 => 0.72.3 react-native-web: ~0.19.6 => 0.19.6 Expo Workflow: managed

Reproducible demo or steps to reproduce from a blank project

Just a simple crash was caused in production which was not detected by Sentry. In case of iOS, Testflight was able to catch it.

MaxAst commented 12 months ago

noticed this as well today, using a dev client

maciekstosio commented 12 months ago

Same issue here, default instructions followed, deploying app using eas update app crashes without any logs. What is more interesting, I have similar problem when I tried bugsnag, so maybe it's more an expo problem - didn't figure out it yet. What could be a clue is that one of the constants from expo-constants EASConfig, EASGoConfig was null after deploy.

muninderkaur06 commented 12 months ago

Same issue here, default instructions followed, deploying app using eas update app crashes without any logs. What is more interesting, I have similar problem when I tried bugsnag, so maybe it's more an expo problem - didn't figure out it yet. What could be a clue is that one of the constants from expo-constants EASConfig, EASGoConfig was null after deploy.

In my case the crash was due to a functionality implemeneted. I trying to use Bugsnag now, I've coordinated with their team and they claim that Bugnag does report native crashes along with exceptions and errors. How you tried contacting them?

maciekstosio commented 11 months ago

I've coordinated with their team and they claim that Bugnag does report native crashes along with exceptions and errors. How you tried contacting them?

I did not, but weird - based on https://github.com/bugsnag/bugsnag-expo/issues/53, they do not support native crashes too.

muninderkaur06 commented 11 months ago

I've coordinated with their team and they claim that Bugnag does report native crashes along with exceptions and errors. How you tried contacting them?

I did not, but weird - based on bugsnag/bugsnag-expo#53, they do not support native crashes too.

I think, I need to remind them of the issue link you mentioned. Well, Is there anything else we can use that would catch native crashes? I really am in need as my project is an organizational project.

axel127 commented 10 months ago

I noticed the same thing today just testing with Sentry.Native.nativeCrash(). It would be great if we could get support for native crash logging.

github-actions[bot] commented 8 months ago

This issue is stale because it has been open for 60 days with no activity. If there is no activity in the next 7 days, the issue will be closed.

matrak-jason commented 8 months ago

I do not think this issue should be closed. I was relying on Sentry for crash detection and I too have found that whilst the Android crash console shows crashes, none of those are reported in Sentry.

gunnartorfis commented 6 months ago

Definitely still an issue - native crashes aren't being captured by sentry-expo (SDK 50, sentry-expo ~7). I haven't tried it with a bare RN app.

topherauyeung commented 6 months ago

I am also experiencing this issue on sentry-expo: ~7.1.0 and expo: ^49.0.13. i am finding that Datadog is correctly capturing the native crash log, but there is no corresponding crash in Sentry, which is frustrating because I was hoping that the source maps that Sentry is able to make use of would shed more light on what is causing the crash, which is notoriously difficult to ascertain for Expo/React Native crashes because the native crash log only displays the native stack trace.

krystofwoldrich commented 6 months ago

Hello everyone, @sentry/react-native now supports Expo out of the box!

This package reports native crashes to Sentry, the application must be built in the release mode. Expo Go is supported but without native crashes. Expo Dev Client is also supported.

Update to https://github.com/getsentry/sentry-react-native/releases/tag/5.16.0 or newer to get all the new features.

Migration guides available:

If you have any questions or have found a crash that is not reported please open new issue in https://github.com/getsentry/sentry-react-native

github-actions[bot] commented 4 months ago

This issue is stale because it has been open for 60 days with no activity. If there is no activity in the next 7 days, the issue will be closed.

github-actions[bot] commented 4 months ago

This issue was closed because it has been inactive for 7 days since being marked as stale. Please open a new issue if you believe you are encountering a related problem.