-
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
RN 0.76+ Android + old-arch only - opening notification when the app is killed crashes on start #8131
Comments
Huh - I've only checked 0.76.n with turbomodules working |
Not easy to test this stuff! Luckily I have a big stack of issues related to FCM so I went ahead and set up some scaffolding in #8143 and on https://github.com/mikehardy/rnfbdemo/blob/main/make-demo.sh (on a branch unpushed so not visible yet), so I can now test this stuff. This is largely repetitive but here is what I see when I follow these steps:
So I did not see exactly what you saw, but I saw something... No investigation yet but reproduction is frequently 90% of the problem with things like this crash trace logcat output
|
Some more subtleties while testing:
Recompiling with newArchEnabled=true works to bring the functionality back, but this may understandably be a problem for some |
Upstream: facebook/react-native#47592 |
It seems a bit strange but... if you leave the notification in the notification center, without clearing it, and try to open the app, the crash occurs. At least here it is happening like that. |
There are many crashes in production for us, all the reports from the users are aligned with what i reported above. App is not in the background. The user tap on the notification from the tray and the app crashes on start. Downgrading to RN 0.75.n solves the problem. |
@oraylan that's bizarre - tougher to reproduce as well, I was able to see it the first time I tried, then it failed the next 3 times. So your report is inconsistent but I did see it. Here's the trace I got when that crash happened, repro was:
crash trace logcat output
This looks like the important line:
|
I updated react native to 0.76.0 or above, for example 0.76.1, and the problem was fixed |
@7chenys that's surprising, because we just got a patch against react-native that I was able to test and find works against 0.76 + old-arch literally today, and it's not merged yet - facebook/react-native#47592 / facebook/react-native#48124 RN 0.76 + old-arch does not work in my testing for headlessJS without this patch. |
Upgrading to react-native 0.76.5 solves the issue. |
Yep, this is fixed now upstream but you must be current. It was only just released yesterday. |
I'm experiencing a crash on startup of my app, and I think it's this same issue as it's only come about since upgrading to RN 0.76, old architecture. Can anyone confirm if it's the same issue from this log?
|
@gavrichards hey there - none of the problems I saw or worked on were on iOS, they were all Android problems. This looks like something unrelated. I'd search carefully in the react-native repo as it appears to be something about the JSI Inspector ? |
@mikehardy The problem I've flagged is Android too. I'm curious what makes you think it's unrelated? |
@gavrichards I'm sorry, I misread the stack trace! Slightly different format than I'm used to, much closer to the iOS stack traces I see. At any rate, I do think it's unrelated, none of the crashes I saw had anything in the trace about JSI Inspector, they were all different From facebook/react-native#47592 - you can see the errors and traces that popped up with that one |
Thanks. Yes, I've studied the issue you linked to extensively.
If you google that, the only place it appears is in this very issue, in your earlier comment. So it just feels like too much of a coincidence not to be related. |
@gavrichards I see what you're saying but my comment also had this important bit:
That is, I was never able to reproduce that one consistently, I don't have a good reproduction for it. The bug(s) that I was working on for old-arch were reproducible every time and had a different trace. Out of curiosity, why not try new arch? I've been struggling with that one myself so you may have a very good reason - but at least with the very latest Notifee release (v9.1.4) new arch seems like the bug-free + future way to go about things. Assuming your other modules are also working with it... |
Sadly I'm stuck using several packages that have yet to add support for it. I only have need for remote push notifications, not ones triggered locally, so I swerved Notifee because it appears to emphasize local notifications over remote ones, so I felt I had a better chance with RN Firebase Messaging. I'm migrating away from https://github.com/zo0r/react-native-push-notification |
@gavrichards notifee is definitely local-notification focused, that was the purpose of peeling it out of |
Ok - thank you for your time and attention, really appreciated. I will continue the hunt. |
[Edit - maintainer update: upstream issue - facebook/react-native/issues/47592 - workaround - use new architecture 0.76.1+ for background FCM to work]
Crashes with EarlyJsError: TurboModuleRegistry.getEnforcing(...): 'PlatformConstants' could not be found. Verify that a module by this name is registered in the native binary.
Only checked with new architecture disabled.
The text was updated successfully, but these errors were encountered: