-
Notifications
You must be signed in to change notification settings - Fork 2.2k
[🐛] getToken() returns not valid FCM token on IOS after deleteToken() #4571
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
Comments
Hi there! This is not intended or expected, but can you reproduce it still with v10 of react-native-firebase?
|
@mikehardy yep still the same after upgrading to v10 |
Well that's unfortunate - thanks for checking, this will likely be an upstream issue - the surest course to resolution will be to do a quickstart reproduction based on: https://github.com/firebase/quickstart-ios/tree/master/messaging (or perhaps even https://github.com/firebase/quickstart-ios/tree/master/installations as I think it is the underlying provider of tokens?) with exact steps / iOS versions etc to reproduce |
Any workaround so far? Unfortunately, we got stuck with this problem as well. |
All information will be present on this issue assuming it is referenced if there is an issue logged upstream - what you see is what we know (not a lot unfortunately) - it needs someone from the community to dig in for triage |
Same problem.
|
@Chachaproper thank you so much for cross-linking that, I had forgotten that. @michaelyav / @mkuligowski this may be thing you need, and we likely need to integrate it into our code as the default (I don't believe there is a PR pending for this, if not and it is confirmed as working we would welcome one and I'd help get it merged + released) |
@Chachaproper thank you man ! i spended a lot of time to find out what the f*ck is happening there >_< |
Hello 👋, to help manage issues we automatically close stale issues.
|
@Chachaproper I don't see any difference with passing params to
|
First of all, thanks for all the hard work on this library 😄 However, having spent several days trying to pin down the issue with our "flaky" push notification behaviour with tediously running differential diagnostic scenarios using FCM console and quadruple checking our systems integration and SDK usage, everything just boiled down to this issue. At this point (and seeing that #3714 has already been closed, I am left wondering, what the "official" solution is at this point?
If the latter is the case, it would be great, if the SDK documentation receives an overhaul to prominently call out this issue and the proposed workaround, so that others don't lose valuable time and hair on a known behaviour that really flies under the radar. 🙇♂️ |
Oh no - I'm so sorry that wasted so much time @tomwanzek - I've pinned this issue to the top of the repo's issue list so it has a lot more visibility, it's already marked for review just not enough time yet to get to it yet. If there is not a real fix there should definitely be something in the documentation That said - as someone who was just up and down the documentation looking for why you were having problems you probably have a pretty good idea where it's missing (maybe in multiple spots - like the tips and tricks page, the usage page and the API documentation...I'm not sure what's best) - there should be an edit button at the top right of every page and if you made a quick PR on any of them that seemed like a good spot I'd merge it immediately |
@mikehardy My apologies, but I did not yet have a chance to cycle back to creating possible additional documentation. However, we seem to have run into a somewhat more severe unintended consequence of the proposed workaround. To explain. When the App is started from Quit state, the splash screen is shown and as soon as possible, the log in screen. We are using chained When the user signs out we are using If the user signs out and then and then quits the app, everything works normally, when the user opens the app and signs in the next time. However, if the user signs out, which bring them back the the sign in screen, and instead of quitting the app, signs back in: The app will hang at The only recovery we currently have for the user is to quit the app in that "hanging" state and open it up again. Interestingly, returning from quit state everything will work as expected again. |
That sounds like something I would try to minimally reproduce using only the native sdks from the Quickstart on the affected mobile operating system, but I'd first make sure that everything was at latest version. There have been new releases of everything since last contact on this one |
We are current w.r.t. Firebase, i.e. RN Firebase SDK for app, analytics and messaging are on 11.4.1. Given that this issue is still open, I am assuming no fix has been part of any recent releases, which would allow us to return to a simple, yet fully functional use of I will see, if/when I have some time to look into creating a minimal repro repo. Have to prioritize core project needs since in the past 1 1/2 weeks a couple of other 3rd party library issues have impacted our builds. |
your assumptions sound correct - no progress on this one as a viable workaround (modulo a failure to resolve promise of course) puts it behind tracking core functionality breaking changes with the native SDKs and we have a more-than-full plate on that unfortunately |
@mikehardy Thanks for the update! Really appreciate the transparency, at least it gives us something to prioritize against as well 😄 |
I believe this is fixed in v12 just released - can reopen if not |
Issue
In our application we use firebase messaging to communicate with the logged in user, therefore we call
getToken()
after the user logs in or in App.js after opening the application if the user is already logged in. If the user logs out of the application, we calldeleteToken()
.On Android, every time we call
getToken()
afterdeleteToken()
, a new token is generated, which we save on our backend and use it to send messages. However, on IOS, in the same scenario, a new token is not generated, but the old token is returned, so when we try to send a message from our backend, we get the error "Request entity not found". Is this an intended action? Should I generate a token for different users in different scope?Project Files
Javascript
Click To Expand
package.json
:firebase.json
for react-native-firebase v6:# N/A
iOS
Click To Expand
ios/Podfile
:# N/A
AppDelegate.m
:// N/A
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:e.g. 7.2.1
Firebase
module(s) you're using that has the issue:messaging
TypeScript
?Y
&3.8.3
React Native Firebase
andInvertase
on Twitter for updates on the library.The text was updated successfully, but these errors were encountered: