RCTFatal + 568 on 5.19.0

[wkirby]

OS:

• Windows
• MacOS
• Linux

Platform:

• iOS
• Android

SDK:

• @sentry/react-native (>= 1.0.0)
• react-native-sentry (<= 0.43.2)

SDK version: 5.19.0

react-native version: 0.73.3

Are you using Expo?

• Yes
• No

Are you using sentry.io or on-premise?

• sentry.io (SaaS)
• on-premise

If you are using sentry.io, please post a link to your issue so we can take a look:

[Link to issue]

Configuration:

(@sentry/react-native)

Sentry.init({
  dsn: 'https://...@sentry.io/...'
  tracesSampleRate: 0.01,
});

---

I have the following issue:

Upgrading to 5.19.0 from 5.18.0 results in RCTFatal + 568 when run in release mode. Running in development mode does not produce an error.

Steps to reproduce:

• Update @sentry/react-native to 5.19.0
• npm install and cd ios && pod install
• npx react-native run-ios --simulator "iPhone 15" --mode Release

Actual result:

The app crashes immediately.

Expected result:

The app should run.

---

For reference, here's the entire diff between a working commit on my project and a commit that will not run in release mode

-   "@sentry/react-native": "^5.18.0",
+   "@sentry/react-native": "^5.19.0",

[wkirby]

Ok, this appears to have been a very chaotic set of interactions across 3 packages, that was very difficult to validate because builds reliably worked in the simulator, but not once archived and distributed via TestFlight.

I am adding this comment for anyone who might be facing something similar.

The problem was an interaction in two different ways:

1. An unexpected interaction between react-native-sentry and react-native-version. Described in this issue, the build phase modification made by the @sentry/wizard for the Bundle React Native code and images adds a triple escape sequence (\\\) in the .pbxproj file. This triple escape throws an error if you attempt to run react-native-version. The naive solution (as recommended elsewhere on the internet to resolve this issue) is to remove 2 of the \s. This will make react-native-version work, and the application will both build and run in the simulator.
2. An unexpected interaction between react-native-sentry and react-native-dotenv, described in this issue. Here, variables that are present in .env and .env.local will correctly override for local, non-release builds --- but will not override correctly for release builds if NODE_ENV=production. Because .env.local is usually gitignored and contains secrets (like SENTRY_DSN, in our case), this resulted in trying to call Sentry.init with a null value for dsn. Again, this issue was not present during build time, nor when running the application in the simulator.

In the end, the solution was:

1. Do a better job properly escaping the modifications made by @sentry/wizard to the build phase
2. Avoid using .env.local

While the end result is that technically there is no bug with react-native-sentry causing these issues, I think it's worth calling out that @sentry/wizard makes somewhat opaque modifications to the React Native build process, that clearly result in hard-to-identify and harder-to-test behaviors that appear only in the production build of the application.

[krystofwoldrich]

Hi @wkirby,
thank you for all the details and the message for other Sentry users.

1. The Xcode .pbxproj parsing issue seems to be caused by the parser used by https://github.com/stovmascript/react-native-version

sentry-wizard updates the React Native scripts into a valid shell script that can be created also directly in Xcode.
The best solution would be to update the mentioned libraries' parser, but I'm not sure if it's maintained since the last release was 4 years ago.

• I opened a new issue here to change the patch to avoid the clash Update React Native Xcode build phase patch to avoid react-native-version crash  sentry-wizard#538

2. Thank you for the mention, this is definitely unexpected, the sentry-cli should be invisible wrapper of the original react-native script.

• New Issue here sentry-cli should not pollute envs for react-native-xcode.sh sentry-cli#1957

[wkirby]

@krystofwoldrich thanks for the follow up, as always I appreciate the work Sentry is doing!