-
Notifications
You must be signed in to change notification settings - Fork 4k
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
🐛 [firebase_messaging] getInitialMessage returning incorrect data #12453
Comments
@keithcwk does this occur on Android or iOS? On my side Android redelivers the same notification multiple times whereas on iOS, once the notification is consumed it does not get delivered again. |
@bqubique it occurs on both Android and iOS |
Hello @keithcwk, are you testing this in release mode instead of debug? Notification will sometime not be properly passed through when using debug mode. |
@Lyokone As i've mentioned, this is a production issue, and we do have genuine complaints from our users. All the instances of the errors are all coming from release mode & production as well |
Same issue here. Running from release mode, force closing and booting from terminated state, it appears to be that the issue is intermittent failure of the entire system. Force closing and booting my app and about 50% of the time I can't even retrieve fcmToken. |
Any update on this? We are facing same issue |
We're facing the same issue on iOS only it seems. I've been trying to reproduce this on through various scenarios, including going into airplane mode, and it seems like getInitialMessage is often empty on iOS but not on Android. We've verified codepath against firebase's doc like @keithcwk did |
For me as well, both getInitialMessage and onMessageOpenedApp is not working. but onMessage is working fine. |
Is there any solution for this problem? |
This really needs to be looked into. This also happens to us in Release with Android. @Lyokone - Do you need additional information? |
Lyokone If I call FirebaseMessaging.instance.getInitialMessage().then((val) => .....) after few times later, (I mean some seconds), it works... In Main initState() - it doesn't work. Upd: I debug that case. When Push received in terminated state, the application starts and call in the Main method InitState() without any click... I think it's not normal. |
I have the same problem, Is there any solution for this? |
Would like to humbly request for this issue to be investigated While recently we haven't been noticing any null data being returned from getInitialMessage, we are currently facing issues where consumed initial messages are returned multiple times, similar to what is reported in the following issues The code given in the example was able to replicate the outcome in release mode |
Do you need more information? |
I just tried this, and it seems to be working fine. Future<void>.delayed(const Duration(seconds: 2), () async {
final message = await FirebaseMessaging.instance.getInitialMessage();
print('getInitialMessage($message)');
}); |
This doesn't work for me at all. Everything works fine on Android tho. But this delay feels really hacky. Where do you have this logic? Somewhere after main.dart? No matter what I do, getInitialMessage is always null on iOS. Flutter 3.23.4 |
The problem with iOS is that the initial notification is received in this delegate method handler: https://github.com/firebase/flutterfire/blob/main/packages/firebase_messaging/firebase_messaging/ios/firebase_messaging/Sources/firebase_messaging/FLTFirebaseMessagingPlugin.m#L224 We have no control over when that becomes available. I used the messaging example app. This call to getInitialMessage always returned But If I press this button: https://github.com/firebase/flutterfire/blob/main/packages/firebase_messaging/firebase_messaging/example/lib/main.dart#L325 I received the initial notification. This is why this works:
There isn't anything we can do about this I'm afraid, we cannot get the initial notification until the system provides it. I would design your app with this consideration in mind. |
I have tried to call this method inside of my initState:
However, even after all 10 tries i.e 10 seconds this is constantly returning me null. So I'm assuming the system never provides the initial message at all. From the Cloud Messaging docs: On iOS, if the user swipes away the application from the app switcher, it must be manually reopened for background messages to start working again. I am indeed doing a release build, swiping to kill / terminate the app and then send a push and click on it to open app again. Could that be the reason this is happening? Or what is meant by the "background messages" in this context? Because all other handlers are working fine on iOS. |
Bug report
Describe the bug
When the app is launched from a cold start scenario,
getInitialMessage
is called, however, the value ofinitialMessage
is null in majority of the casesIn my application, getInitialMessage is used to provide a path to redirect to, located in
initialMessage.data
. However, when logging the value of initialMessage.data, there are multiple instances where it is logged as nullThis causes the redirect from push notification feature to be quite unusable, and our app is facing this issue on production.
Steps to reproduce
Steps to reproduce the behavior:
await FirebaseMessaging.instance.getInitialMessage
is in theinitState
of main.dartgetInitialMessage
Expected behavior
The value of
initialMessage
returns data of initialMessage that was recently consumedSample project
Additional context
Appreciate the effort in reading this report and I hope that this can be fixed
Flutter doctor
Run
flutter doctor
and paste the output below:Click To Expand
Flutter dependencies
Run
flutter pub deps -- --style=compact
and paste the output below:Click To Expand
The text was updated successfully, but these errors were encountered: