-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
🔥 [🐛] Crash not being sent to Firebase using iOS Debug build configuration #6226
Comments
Strange! I just tested this as part of triage for #6207 - and I never saw it fail while I think the issue submitter there never achieved success. It was quite odd, and not the normal resolution. That said: I had successful reports in crashlytics dashboard (following successful messaging from the app during boot). So, this is likely not the fault of the Xcode launch blocking things - you get a different warning in the logs from that: react-native-firebase/packages/crashlytics/ios/RNFBCrashlytics/RNFBCrashlyticsModule.m Lines 46 to 49 in a799c14
Why isn't it detecting that you have enabled things? Unsure, but a common mental model issue is the idea that you change firebase.json then re-run the app and it should work. In fact, you have to change firebase.json, re-run pod install, then run the app and it should work. Why? Because what you want with your firebase.json changes is to actually change Info.plist values (that's where the settings really take hold), and that's only possible if code runs, we run the code that carries values from firebase.json into Info.plist as a pod install ruby script. On android we have gradle power during the build so we're able to do it at build time not install time. Did you definitely run As for avoiding Xcode debugger, I use a version of this simctl command for direct logging when testing crashlytics (usually with out to a file, and then with a grep/search for the crashlytics messages), so I may see the logs and avoid the debugger (it's also what we use in iOS e2e testing in CI to save the simulator log for inspection as needed):
Hopefully that's enough to go on to move things forward a bit? |
You might post your firebase.json as well - with anything proprietary stripped out fine - just to see what it looks like for reproduction if the above doesn't help |
I have been debugging for 2 days, this just isn't working. I have followed all advice.
Crashlytics is working for android, but not for iOS and I can't even tell why the above are not working. I have |
Note that on the crashlytics dashboard the android and ios apps are separate, you have to switch between them in a dropdown near top left. Also, the report is not seen until next app startup. You may have already handled those things. In the meantime @dhruvasagar you haven't provided enough information on your specific problem (with different versions and different configs and different test environment you might have a subtly different problem...), sorry, and I haven't heard back from the original submitter yet. |
@mikehardy it's good to know what you said about running
|
My firebase.json file is posted as part of the description, as indicated in the template. {
"react-native": {
"crashlytics_debug_enabled": true,
"crashlytics_disable_auto_disabler": true,
"crashlytics_auto_collection_enabled": true,
"crashlytics_is_error_generation_on_js_crash_enabled": true,
"crashlytics_javascript_exception_handler_chaining_enabled": true
}
}
|
Sorry I missed the firebase.json! That all looks good 🤔 I'll have to take another crack at reproducing this. The main thing I see is that our e2e test app is on react-native 0.67 still, not 0.68, and I was checking on that. Have you tried this on react-native 0.67 for comparison? Just curious. I won't have time to compare 67 vs 68 react-native versions for a little bit unfortunately, but right now that's all I can think of as a difference between what I see working and what you are reporting not working |
One other thought - you can check the generated info.plist file from the build directory to see the results (or lack of same) from our ruby script, it will show whether interpolation is working, the script itself is in our app package |
@mikehardy I have the exact same firebase.json as mentioned in this issue. I am on React I have tried several work arounds, suggestions, but nothing had made any difference. |
Okay - I definitely had success with it on react-native 0.66.x. Really odd. Perhaps something about the ruby + cocoapods execution environment? Rather than speculate about what might work, here's evidence from the latest E2E run. We preserve simulator logs as a GitHub workflow artifacts, so you can see the log here https://github.com/invertase/react-native-firebase/actions/runs/2245976888 And you can see all of the software versions in question by referring off the workflow run's definition + system image And it is working 🤔
Maybe intel mac vs M1 mac? But in the other recent issue like this (#6207) that was an intel mac. Most of my testing is intel mac so it's a possible difference but I assign low-probability. Very curious for results of inspection of the processed / pre-pack-into-.app Info.plist For our e2e app named When I take the {
"messaging_android_notification_channel_id": "",
"app_data_collection_default_enabled": false,
"google_analytics_automatic_screen_reporting_enabled": true,
"android_task_executor_maximum_pool_size": 10,
"messaging_android_headless_task_timeout": 30000,
"crashlytics_debug_enabled": true,
"android_background_activity_names": "NotActuallyAnActivity",
"google_analytics_ssaid_collection_enabled": true,
"analytics_collection_deactivated": false,
"messaging_android_notification_color": "@color/hotpink",
"rnfirebase_json_testing_boolean_true": true,
"crashlytics_auto_collection_enabled": true,
"analytics_auto_collection_enabled": true,
"in_app_messaging_auto_collection_enabled": false,
"android_bypass_emulator_url_remap": false,
"crashlytics_disable_auto_disabler": true,
"android_task_executor_keep_alive_seconds": 3,
"app_log_level": "debug",
"crashlytics_javascript_exception_handler_chaining_enabled": false,
"analytics_default_allow_ad_personalization_signals": true,
"perf_auto_collection_enabled": false,
"app_check_token_auto_refresh": false,
"perf_collection_deactivated": false,
"crashlytics_is_error_generation_on_js_crash_enabled": true,
"messaging_ios_auto_register_for_remote_messages": false,
"google_analytics_adid_collection_enabled": true,
"crashlytics_ndk_enabled": true,
"rnfirebase_json_testing_string": "abc",
"analytics_idfv_collection_enabled": false,
"rnfirebase_json_testing_boolean_false": false,
"messaging_auto_init_enabled": false
} which looks exactly like I expect I'm out of time to look at this for the day but I've got local success here at least on intel mac + react-native 0.67 and in the github workflow environment, which allows inspection of every single thing + is 100% reproducible. Somewhere in the difference between those environments and your environments is the problem. Wish I knew what it was |
cocoapods is installed via homebrew and I have a separate ruby version manager (asdf). Would it help to use system ruby that ships with macos ? btw, I am on a macbook with the m1 max chip |
I use rvm personally and ruby-3.1.2 currently, with cocoapods installed as a gem. And it works. I have a different environment which also works (a couple actually, intel and m1). So the burden of proof is on reporters now to investigate differences as I can not reproduce and I've provided full spec for success reproduction, I'm not sure what else I can do I cannot speculate on the infinite variety of possible dev environments though, that's inefficient use of time, right? |
@mikehardy I agree, there must be an environment difference. I will check the environment you are referring and try to find something useful. I can't find the I will check the situation for React Native 0.67 and post any useful results. |
Yes - that path is from the root folder, but that's because we specify a build folder in our build for the app via command line, you may find it also in |
Thanks! I've found the Info.plist there. My <key>firebase_json_raw</key>
<string>e30=</string> Where Everything points to a problem reading the By the way, I've tried the same test in React Native 0.67, with the same results: |
definitely looks like firebase.json is not seen and thus not interpolated somehow. I believe our ruby script, which is in the app package, prints some information during it's execution, and the execution itself is happening from a cocoapod hook we use. Should be possible to instrument the script with some logging to see what's what I hope |
This may be related, but as I'm gearing up to handle the new SDKs releasing during Google I/O week here (firebase-ios-sdk v9, firebase-android-sdk v30) I started doing baseline testing and I think I have something related here. I'm starting to see failures to see the config JSON in our e2e harness, but only on macOS 12, and only recently - it definitely used to work, I do check it semi-frequently. This is more difficult then the normal bug for us to reproduce because so much of our test infrastructures is still macOS 11 (github actions
I note the original reporter @lucas-cz is on macOS 12, so this may be reproduced. Is anyone seeing this on macOS 11 or is this all macOS 12? |
@mikehardy I am on 12.3.1 |
Thanks for reporting @dhruvasagar macOS 12.3 - released on March 24 - removed the python interpreter, python3 exists but our iOS config machinery relied on
I traced the failure to that line. I can do a one-liner node base64 so that we don't need to rely on python, however that's actually problematic as the node binary is - unbelievably - not always available on the Xcode compile path (strange but true). PRs in flight for the fix and for the test-fix (to make sure our tests do fail on macOS12 and we see it, then they'll pass when the fix merges...) |
That fixed it! I updated Thanks @mikehardy for the extensive support 😁. |
So happy to hear that! Would you believe that even the macos-12 runner in github workflows includes a python binary (for convenience, which I do understand) so not even updating to macos-12 runner showed this. Only way to reproduce was to have a mostly stock macos 12.3+ machine and run the e2e harness. I've got a personal task to update more of my personal test infrastructure to have that, they're mostly macos11 VMs and I've been stuck on getting nested virt for android emus going in macos12 VMs. Just a tangle of things here making us blind to this. Glad it's nailed for now though |
Issue
Crash reports are not being sent to Firebase when building for iOS using Debug build configuration, even with
crashlytics_debug_enabled
set totrue
. My configuration is based on this article: https://invertase.io/blog/react-native-firebase-crashlytics-configuration.For Android (Debug and Release) and iOS (Release) it's working fine.
To test it, i am running the app from Xcode, stopping and reopening it from the desktop icon to prevent the Xcode debugger from blocking the reports.
I have noticed that the Xcode logs (at app launch) are indicating that the library is reading the value of
crashlytics_debug_enabled
as0
(line 2):The app that I am using is a Sample React Native App created with
npx react-native init
and the followingApp.js
:Project Files
Javascript
Click To Expand
package.json
:firebase.json
for react-native-firebase v6:iOS
Click To Expand
ios/Podfile
:AppDelegate.m
:Android
Click To Expand
Have you converted to AndroidX?
android/gradle.settings
jetifier=true
for Android compatibility?jetifier
for react-native compatibility?android/build.gradle
:// N/A
android/app/build.gradle
:// N/A
android/settings.gradle
:// N/A
MainApplication.java
:// N/A
AndroidManifest.xml
:<!-- N/A -->
Environment
Click To Expand
react-native info
output:react-native-firebase
version you're using that has this issue:14.9.1
Firebase
module(s) you're using that has the issue:Crashlytics
TypeScript
?N
React Native Firebase
andInvertase
on Twitter for updates on the library.The text was updated successfully, but these errors were encountered: