HeadlessTask: Could not enqueue microtask because they are disabled in this runtime #47570
Comments
mbpictures
added
Needs: Triage 🔍
Type: New Architecture
react-native-bot
added
Needs: Author Feedback
Needs: Repro
|
Warning Missing reproducer: We could not detect a reproducible example in your issue report. Please provide either:
|
|
It will be helpful if you provide a repro as well. You can use this template. |
|
Repro added in issue description |
github-actions
bot
added
Needs: Attention
|
@shubhamguptadream11 will it be possible to include a fix for this issue in version 0.76.2? (Android apps using FCM can't use new arch until then) |
|
0.76.2 is already out, this would maybe be possible in 0.76.3. Hopefully possible... |
|
0.76.2 is out but with the commit 9f65442 Does this mean that this issue is fixed? @mikehardy What do we need for 0.76.3? |
|
@cipolleschi it might be, we're collaborating over on #47592 so you know I'm looking at this headlessJS stuff. This was next on my list to check out for repro because it seems that it might be working well now. My repro for 47592 wasn't done with this in mind though so I wanted to check it specifically. I'll do so and let you know what I see |
|
Testing results - I added a branch with Notifee to my reproducer in for #47592 (which is similar to the reproducer here, except no need to send it an FCM, you can trigger things via All testing followed this process:
So that's no good. 0.76.0 seems to be ❌
Everything chained through correctly - and a Notifee notification posts, everything works? 0.76.1 seems like ✅
same as 0.76.2 - everything seems to work, I get a notification etc, everything works ✅ So:
|
|
I am simply not able to reproduce this anymore, I really tried. Anyone is feel free to take my example from this branch here and extend it as needed, but I/we will need your exact steps to reproduce this in order to find it: https://github.com/mikehardy/old-arch-android-receiver-boot-crash/tree/notifee-integration-issue47570-repro I'm going to consider this closed though and start recommending that people try notifee and react-native-firebase on 0.76.2+ with new arch on android and iOS, I can't find problems with either of them anymore |
|
I had the same issue with 0.76.3, upgrading react-native-firebase/app to ^21.5.0 seems to have fixed the issue |
|
@romanakash from version what of react-native-firebase/app to 21.5.0? There have not been any new-architecture-related items released in react-native-firebase/app in a long, long time other than the switch from |
|
From 20.1.0 From my experience there was another error thrown by my code which was a mistake, so I made a change and when fast refresh tried to refresh it got stuck with the micro task error After upgrading the firebase version I got the same error due to my own code but when fast refresh refreshed I did not get the micro task error |
|
@romanakash in fact the one and only time I saw this was similar - I had two apps I was reproducing on and I saw it when one of them accidentally (through a test methodology failure on my part) loaded the bundle from the other app, resulting in all sorts of problems including a microtasks error. When I kept my methodology clean + fully reproducible I was never able to reproduce the microtasks error on current versions of everything So this is possibly confirmation bias, but my experience pretty much matches yours And I still cannot reproduce this problem anymore (a good thing!). I believe headlessJS is working with new architecture on current versions of everything |
|
Well for me it seems like I still have this error. I released an app update yesterday including react native 0.76.2 and today I saw a lot of crashes in firebase crashlytics: |
|
@mbpictures have you updated Firebase to ^21.5.0? Can you try with that version? |
|
@cipolleschi thanks for the hin, but I already updated firebase to version 21.5.0 |
|
Yeah - unfortunately nothing in RNFB recently is expected to affect this. What I'm looking for in order to nail this down is
Feel free to use this as a start - it's very self-contained and I was able to reproduce things with it: I even have a branch on it that tweaks things a bit specifically to match your handler setup in your reproducer: and I just couldn't see it. I don't think react-native-firebase is doing anything magical in the chain of receiver -> service -> headlessJS tasks so it should be a valid reproducer, but maybe I'm wrong. If the app has to be an FCM / react-native-firebase app, then knowing the exact FCM JSON contents I should use, and the exact state the app needs to be in before delivery, would really help me. Then I could drop it into the a branch I have going here that allows me to check FCM / Android interaction: But the exact FCM and exact steps to reliably reproduce it are a strict requirement here since I'm failing to reproduce at the moment |
|
After a lot of fiddling around, I successfully reproduced it (using the same repo as provided in the issue description). The key point was to create a release build with proguard enabled. Some detailed reproduction steps:
While following these exact steps, the issue occurs every single time, even on the newest RN version 0.76.3 |
|
Ah okay - I was definitely testing on debug builds though I can create release builds. |
|
@cipolleschi I found in my case it was not a React Native issue but a 3rd party library issue ( react-native-push-notification) which was causing the issue. Now I updated my code to work with Notifee and everything works as expected without this crash. |
|
@cipolleschi I believe it is closable yes. As far as I can tell, react-native 0.76-current + new architecture in bridgeless mode is working. I did not type "working well" because I will admit troubleshooting when it fails is quite difficult. I'm not sure if you have any insight into technical ability to expose the underlying module-specific errors that cause problems, but that would be a really really big help. In the Notifee case, there should have been a clear stack trace with Notifee frames saying NoClassDefFound, but it appears everything helpful is lost and we just get "Could not enqueue microtask..." as an error. So, headlessJS+new-arch is working, but modules do have problems at the module level and it's hard to fix them at current. There is still a headlessJS+old-arch issue I believe, it is separate and tracked separately though of course, just noting it. Hope that is useful feedback? Welcome back! :-) |
|
Just confirmed 0.77.0-rc.1 as well, things looking good in headlessJS+new-arch 🫡 |
|
@mikehardy Thanks, that was useful. In 0.77 we reimplemented the early JS reporting pipeline, reimplementing it in C++. Errors should bubble up better and with a better stack trace in that version. Hopefully, it will help in these cases too. I'll close this, then. Thank you so much for spending all that time on this! |
|
Hey @cipolleschi - I like the idea of better error reporting, it was so difficult to test this because of the swallowed root cause information so I thought I'd test it on 0.77 to see if it was improved as you mentioned When I moved my reproducer to 0.77.0-rc.1 (hot off the presses!) I do not see any improvement in error reporting in the headlessJS "startup failed because native module had a crash" exception case The root cause Just wanted to report that 0.77 is not an improvement for this case at least If the module works, headlessJS works though - I'm just talking about how react-native reports module errors in headlessJS at this point. |
|
I am using React Native 0.75.4 and "@aws-amplify/rtn-push-notification" version "^1.2.31" for notifications. In AWS, Firebase is configured as the notification provider for Android. When I run the app in debug mode, I receive multiple notifications without any issues. However, after creating the release APK, the app crashes upon receiving a notification after 3-4 notifications have been received. Here is the crash log: In my React Native code, I have added a notification receive handler. When the app crashes, that method gets called, and the log "receive notification when app in background:::::::::::::::::::::::::::::::::::::::::::" inside that method is printed in Android Studio Logcat. Can anyone help me with this? |
|
@mikehardy thanks for checking with the new version. I'll let the person working on the error pipeline know that there are cases where we are not covered yet. @HemangiVekaria if you are on 0.75, you are still on the Old Arch. Please move the conversation to the Old Arch issue: #47592. As far as I can see that has been resolved as well by this commit: 3c747eb We have to make a patch release which includes the commit. |
Can i get patch file please? |
|
hi @cipolleschi @mikehardy we are experiencing the crash in our latest Android rollout using the new architecture. This issue was not detected during internal testing but has now started affecting a growing number of users. Any insights or guidance on resolving this would be greatly appreciated. Some more context:
|
@cipolleschi @mikehardy The crash persists even after removing all code related to HeadlessTask. The only references to HeadlessTask in the project (including dependencies) are found in: react-native: "0.76.2" Would greatly appreciate your input |
|
@gituser8796 you should update to react-native@0.76.5 |
|
@HamoBoker will give it a try although we're using the new architecture, thx! |
|
@mikehardy @cipolleschi it still happens even on 0.76.5 - also added changes make by notifee to our proguard-rules.pro |
|
@gituser8796 you'll need to provide a reproducible example. I can say that the error "Could not enqueue microtask because they are disabled in this runtime" is what all native module errors get mapped to in headlessJS. It could be anything. Any module. For a while it was in react-native new arch and old arch. New arch was fixed first and has worked since I believe 0.76.0 or .1. old-arch was just fixed in react-native with 0.76.5. But modules, they may still have problems. Notifee definitely did until notifee v9.1.3. react-native-firebase has worked fine for a while, well before v21. But there could be some other problem. No way to know without an example that reproduces it. My reproducer for the modules I maintain no longer shows any problems though and I haven't heard any specific scenarios I could try even, so I can't advance this. |
|
@mikehardy We managed to trace the offending code to a dependency that was attempting to call Reanimated too early (during file imports) and have removed it. However, we are still receiving reports of the Notifee crash from Firebase, though, unfortunately, no clear scenario has been identified yet. Do you have any suggestions on how to move forward? |
|
+1 Facing the same issue as @gituser8796 - we are also using new arch on "react-native: "0.76.5"" with the latest notifee and firebase libraries installed. I am also able to reproduce this in debug mode and I get this warning in my console. The stacktrace leads back to HeadlessJsTaskContext |
|
Solved the issue on our end. We were initializing our firebase remote config prior to calling the background message handler. The initialization was a promise and we were awaiting it, removing the await and letting it run synchronously solved the issue for us. I guess if you have any promises running prior to the handler either remove it or defer it to after initializing the background message handler. It seems to mess with the creation of a headless task on Android. |
|
For anyone following along at home - there was one more new architecture + headlessJS issue (a startup race where module beat react-native to startup so ReactContext was null in module...) in Notifee resulting in a crash. I just released a fix for that yesterday. It is possible as mentioned above that playing around with how you used module APIs during startup could workaround it and let you startup headlessJS correctly but really it was a module problem that needed a fix. I remain unaware of "upstream" (that is, here: react-native internal code) issues with headlessJS at the moment but it's clearly difficult for modules to get correct in the new arch environment |
|
@mikehardy in the meanwhile we reverted back to old architecture. Is it safe to use 9.1.4 with old architecture? |
|
For anyone seeing this:
You can just supply an empty background message handler ( @gituser8796 I do believe 9.1.4 is safe with the old architecture. However 9.1.4+ of notifee should be safe with new architecture as well |
|
After assembleRelease and installing in real device and emulator with release.apk 
|
|
I updated my react-native version from 0.75.4 to 0.76.3 and now it's working. I am not getting any errors or crash |
Can u try to build it to apk and install to device? that's when error happended |
I did that. I uploaded my app on play store also. And it's working without any issue. |
|
do u use these lib? or you use notifee |
|
i am using |
alright i'm looking for react-native-push-notification 8.1.1 |
That one has problems and hasn't been updated. I maintain notifee which also handles local device notifications and had to do a lot of work to handle bridgeless mode. I suspect react-native-push-notification module hasn't done the work. |
Description
I'm using react-native-firebase messaging to receive firebase push notifications using this line:
However the App Crashes with this error:
The symbolicated stacktrace looks like this:
Steps to reproduce
React Native Version
0.76.1
Affected Platforms
Runtime - Android
Areas
Bridgeless - The New Initialization Flow
Output of
npx react-native infoStacktrace or Logs
Reproducer
mbpictures/react-native-microtask-repro
Screenshots and Videos
No response
The text was updated successfully, but these errors were encountered: