expo / sentry-expo

MIT License
202 stars 83 forks source link

NativeArgumentsParseException: RNSentry.captureEnvelope got 3 arguments, expected 4 #295

Closed ToniNikolaev23 closed 1 year ago

ToniNikolaev23 commented 1 year ago

Summary

Hello i have this kind of error in Sentry: NativeArgumentsParseException: RNSentry.captureEnvelope got 3 arguments, expected 4 expo-sentry version is "sentry-expo": "^4.0.0", In App.jsx: Sentry.init({ dsn: SENTRY_DSN, enableInExpoDevelopment: true, debug: SENTRY_DEBUG, });

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

bare

What platform(s) does this occur on?

Android

SDK Version (managed workflow only)

No response

Environment

expo-env-info 1.0.5 environment info: System: OS: macOS 12.6 Shell: 5.8.1 - /bin/zsh Binaries: Node: 18.11.0 - /opt/homebrew/bin/node Yarn: 1.22.19 - ~/.yarn/bin/yarn npm: 8.19.2 - /opt/homebrew/bin/npm Watchman: 2022.10.17.00 - /opt/homebrew/bin/watchman Managers: CocoaPods: 1.11.3 - /Users/tonistoyanov/.rvm/gems/ruby-2.7.5/bin/pod SDKs: iOS SDK: Platforms: DriverKit 21.4, iOS 15.4, macOS 12.3, tvOS 15.4, watchOS 8.5 IDEs: Android Studio: 2021.2 AI-212.5712.43.2112.8609683 Xcode: 13.3/13E113 - /usr/bin/xcodebuild npmPackages: expo: ~44.0.2 => 44.0.6 react: 17.0.1 => 17.0.1 react-dom: 17.0.1 => 17.0.1 react-native: 0.64.3 => 0.64.3 react-native-web: 0.17.1 => 0.17.1 npmGlobalPackages: eas-cli: 2.4.0 expo-cli: 6.0.6 Expo Workflow: bare

Reproducible demo or steps to reproduce from a blank project

I dont know from where this errors come.Cannot reproduce

christophe-chausseray commented 1 year ago

I have the same issue on a managed workflow with expo SDK 46

kbrandwijk commented 1 year ago

Which version of @sentry/react-native do you have in your dependencies?

ToniNikolaev23 commented 1 year ago

"@sentry/react-native": "^4.2.2"

christophe-chausseray commented 1 year ago

I updated with the fixed version 4.2.2 of @sentry/react-native to have the same as the one specified in dependency of sentry-expo (https://github.com/expo/sentry-expo/blob/main/package.json#L45). It solved the problem on my project.

krystofwoldrich commented 1 year ago

This is caused by the change of native implementations we made in @sentry/react-native v4.4.0.

A clean build is needed so the native code gets rebuilt.

MorenoMdz commented 1 year ago

This is caused by the change of native implementations we made in @sentry/react-native v4.4.0.

A clean build is needed so the native code gets rebuilt.

Hey, it started happening to use after we upgraded the Sentry version, is it fixed with the newest Expo sentry versions?

krystofwoldrich commented 1 year ago

@MorenoMdz To fix this you need to do a clean build of your app. It needs to rebuild the native code.

gastondisacco commented 1 year ago

I'm experiencing same issue. @krystofwoldrich you mean sending store release instead of OTA with EAS? Thanks.

andrejpavlovic commented 1 year ago

For Expo SDK 47, dependencies should look like this:

  "sentry-expo": "~6.0.0"
  "@sentry/react-native": "4.9.0",
krystofwoldrich commented 1 year ago

I'm experiencing same issue. @krystofwoldrich you mean sending store release instead of OTA with EAS? Thanks.

Yes, the OTA update only changes the JS code, but we have changed the native implementations for Android and iOS.

gasolin commented 1 year ago

@krystofwoldrich thanks, it will be nice to add expo cli warning that heads up these package changes require a store update

krystofwoldrich commented 1 year ago

@gasolin Yes, that would be a cool feature.

bradjones1 commented 1 year ago

Related: https://github.com/getsentry/sentry-react-native/issues/2505

I can confirm that pinning @sentry/react-native to 4.9.0 fixes the error in the title, however I'm a bit perplexed as to why that specific version works and the latest (4.12.0) doesn't. Also, if this is a known limitation, I think the Expo package should put a version constraint that would conflict with a known incompatible Sentry RN package? AFAICT the underlying issue was introduced in 4.4.0 so curious why it isn't broken in an intermediate release?

A quick compare of 4.9.0 to 4.12.0 doesn't jump out at me but perhaps someone knows what's gone on, here. I'd like to not pin to a specific version... forever?

krystofwoldrich commented 1 year ago

@bradjones1 As you mentioned the change was introduced in 4.4.0. So there should not be any difference between 4.9.0 and 4.12.0. Maybe it's just poison cache? Have you tried a clean build? Can you share a minimal reproducible example?

github-actions[bot] commented 1 year 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 1 year 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.