Open jeungeun0 opened 4 months ago
I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.
For the time being you can avoid constructing the dictionary if the FCM token is nil and log a non-fatal error manually through Crashlytics instead. If you manually implement the didRegisterForRemoteNotificationsWithDeviceToken
, does it always execute before you construct the userInfo
dictionary in HDLoginPresenter.m
?
For the time being you can avoid constructing the dictionary if the FCM token is nil and log a non-fatal error manually through Crashlytics instead. If you manually implement the
didRegisterForRemoteNotificationsWithDeviceToken
, does it always execute before you construct theuserInfo
dictionary inHDLoginPresenter.m
?
I modified it to insert an empty string (””) into the NSDictionary when the FCM token is nil. However, what I want to understand is the fundamental reason why the FCM token is not being received. Because even though I prevented Crashlytics by inserting an empty string, if those users (who experienced the crash) do not run the app again, the push notifications will not be sent. (The userInfo is created as part of the process to save the FCM token on the server. If it is not saved on the server, push notifications will not be sent.)
I am implementing didRegisterForRemoteNotificationsWithDeviceToken
in the AppDelegate
, and there, I am notifying Firebase that the deviceToken has been issued using [FIRMessaging messaging].APNSToken = deviceToken;
. According to the debugging results, the sequence of calls is as follows:
umm... I have been continuously thinking about and debugging this error. Then I realized that the error occurrence date doesn’t matter.
I speculate that the fcmToken might have been intermittently coming as nil, but it was reported to Crashlytics because I added new code to create an NSDictionary
using a singleton variable. (The updated version was uploaded on June 20th.) So, I discovered an issue that I hadn’t recognized before.
To summarize, the error occurred because I added code in HDLoginPresenter.m
(refer to the description above), but the issue of fcmToken coming as nil has potentially been happening all along. The new code(of HDLoginPresenter.m
) addition revealed this latent issue.
closed button clicked incorrectly and was re-opened...
I am implementing didRegisterForRemoteNotificationsWithDeviceToken in the AppDelegate, and there, I am notifying Firebase that the deviceToken has been issued using [FIRMessaging messaging].APNSToken = deviceToken;. According to the debugging results, the sequence of calls is as follows: [...]
In didReceiveRegistrationToken:
, can you also log a non-fatal if the token value is ever nil?
I am implementing didRegisterForRemoteNotificationsWithDeviceToken in the AppDelegate, and there, I am notifying Firebase that the deviceToken has been issued using [FIRMessaging messaging].APNSToken = deviceToken;. According to the debugging results, the sequence of calls is as follows: [...]
In
didReceiveRegistrationToken:
, can you also log a non-fatal if the token value is ever nil?
I’m not sure if I understood @morganchen12 question correctly, but originally, I did not check for nil and directly assigned the value to the singleton’s variable. Since the variable type is NSString, it did not cause a fatal error. The error occurred later in the process when the singleton variable was assigned to an NSDictionary and it was nil.
In the revised code, if fcmToken is nil in didReceiveRegistrationToken:
, it re-requests the fcmToken, and if it’s still nil, a custom error is logged to Firebase Crashlytics (the actual user won’t know about the error).
Although the nil check is done, is there a way to prevent fcmToken from being nil from Firebase in the first place? Due to this issue, some users are unable to receive push notifications.
I have discovered something new.
If it were a Firebase server issue, the same null value should occur on Android as well, but it only happens on iOS. Here are the reasons for this judgment:
Each time the app runs, it receives the fcmToken and saves it to the server only if it exists (the app crashes if it is null). However, at some point, we started getting file not found
errors when sending push notifications from the server.
Although it is speculative, the occurrence frequency data is similar, and since the server checks whether it is iOS or Android, I reviewed the logs and found that it only happens on iOS. It seems to be an organically connected issue.
(Even before the code I uploaded in June, the app was set to crash if the fcmToken was null, but this issue started occurring recently, so there must be some changes or issues on the Firebase side.)
When the fcmToken is nil on an iOS device, an error occurs, preventing it from being saved to the server. In this case, the fcmToken stored on the server remains the previous (expired) fcmToken, leading to the problem.
Therefore, it seems to be an issue with the SDK rather than the API.
I understand that issues are closed after 7 days of inactivity… I want to update the SDK to the latest version and monitor whether null values still occur, but it is practically difficult to test with the app that actual users are using. So, I have safely added a logic to re-request the fcmToken after a null check (as mentioned in a previous comment). This seems to resolve the issue. We plan to release a new version soon, so I should be able to comment on whether the issue is resolved. If there are any additional updates, I will add them as comments.
I believe this is similar to what I am seeing.
pod FirebaseMessaging, '10.28'
What seems to be happening in my case:
So the point here is that I cannot get a valid FCM token after the first success. There is definitely something wrong here, as it is working for Android, no problems.
I'm going to be downgrading the SDKs to see if a specific update introduced this issue.
@jeungeun0
I have discovered something new.
If it were a Firebase server issue, the same null value should occur on Android as well, but it only happens on iOS. Here are the reasons for this judgment: Each time the app runs, it receives the fcmToken and saves it to the server only if it exists (the app crashes if it is null). However, at some point, we started getting
file not found
errors when sending push notifications from the server. Although it is speculative, the occurrence frequency data is similar, and since the server checks whether it is iOS or Android, I reviewed the logs and found that it only happens on iOS. It seems to be an organically connected issue. (Even before the code I uploaded in June, the app was set to crash if the fcmToken was null, but this issue started occurring recently, so there must be some changes or issues on the Firebase side.) When the fcmToken is nil on an iOS device, an error occurs, preventing it from being saved to the server. In this case, the fcmToken stored on the server remains the previous (expired) fcmToken, leading to the problem. Therefore, it seems to be an issue with the SDK rather than the API.
There is a difference here betwen Android and iOS. Which can point to a Firebase server issue.
Android: FCM Token iOS: APNS Token then FCM Token.
I've been doing some testing on my application. It looks like when the Firebase SDK first boots and we prompt the user for Push Notification Prompt (approval) we get a valid APNS token, and then create a valid FCM token. However on repeat boots, the APNS token is returned as nil
but the FCM token is still defined.
There were related changes in 10.19.0 and 10.20.0, so it would be interesting to see if going back to 10.18.0 makes a difference https://github.com/firebase/firebase-ios-sdk/blob/main/FirebaseMessaging/CHANGELOG.md
There were related changes in 10.19.0 and 10.20.0, so it would be interesting to see if going back to 10.18.0 makes a difference https://github.com/firebase/firebase-ios-sdk/blob/main/FirebaseMessaging/CHANGELOG.md
I went back to 10.11 same problem. 😞
The 10.6.0 change looks like the next earliest related SDK change.
Another possibility is a race condition in the app.
The 10.6.0 change looks like the next earliest related SDK change.
Another possibility is a race condition in the app.
Going back to 10.6 there is still an issue with the APNS token on repeat application boots.
I'm going to submit a ticket with Firebase. In my opinion this seems to point to a server side problem on their side 🤔
Has there been any update on this? Is there a version or work around? I am running into similar issue which has been a hinderance during app store submission.
Description
We have been experiencing intermittent errors in retrieving the token via Firebase Crashlytics since June 24th. Upon analysis, it appears that the fcmToken is occasionally nil in the
didReceiveRegistrationToken
method. While I have searched for similar issues, none seem to match our case.We are currently storing the fcmToken in a singleton variable (I understand this is not ideal, but we plan to address it after an upcoming security review). The fcmToken is set exclusively in the
didReceiveRegistrationToken
method, and is only retrieved elsewhere in the code.Example:
I initially considered that the issue might be due to calling the variable before the singleton instance is created, but this seems unlikely as the error has been consistently occurring 1-8 times daily since June 24th. (Interestingly, this error did not occur before June 24th and has only started affecting some users since then.)
I checked the Firebase SDK version change log and noticed an update on June 24th. Although the update details do not specifically mention changes related to fcmToken, I suspect there might be a compatibility issue if there were server-side changes.
Attached are the relevant Firebase Crashlytics logs and information. Please let me know if additional data is required.
Note: The code on line 96 of HDLoginPresenter.m is as follows:
This error occurs because we are attempting to insert a nil value into the NSDictionary.
Reproducing the issue
I tried debugging by manually setting the singleton variable to nil, which resulted in the same error in the code. However, I could not replicate this issue during actual use. All the information we have comes from the errors reported in Firebase Crashlytics. (We are conducting tests in our development environment on actual devices, but have not been able to reproduce the error.)
Firebase SDK Version
10.25.0
Xcode Version
15.3
Installation Method
CocoaPods
Firebase Product(s)
Messaging
Targeted Platforms
iOS
Relevant Log Output
If using Swift Package Manager, the project's Package.resolved
Expand
Package.resolved
snippet```json Replace this line with the contents of your Package.resolved. ```
If using CocoaPods, the project's Podfile.lock
Expand
Podfile.lock
snippet```yml PODS: - FirebaseAnalytics (10.25.0): - FirebaseAnalytics/AdIdSupport (= 10.25.0) - FirebaseCore (~> 10.0) - FirebaseInstallations (~> 10.0) - GoogleUtilities/AppDelegateSwizzler (~> 7.11) - GoogleUtilities/MethodSwizzler (~> 7.11) - GoogleUtilities/Network (~> 7.11) - "GoogleUtilities/NSData+zlib (~> 7.11)" - nanopb (< 2.30911.0, >= 2.30908.0) - FirebaseAnalytics/AdIdSupport (10.25.0): - FirebaseCore (~> 10.0) - FirebaseInstallations (~> 10.0) - GoogleAppMeasurement (= 10.25.0) - GoogleUtilities/AppDelegateSwizzler (~> 7.11) - GoogleUtilities/MethodSwizzler (~> 7.11) - GoogleUtilities/Network (~> 7.11) - "GoogleUtilities/NSData+zlib (~> 7.11)" - nanopb (< 2.30911.0, >= 2.30908.0) - FirebaseCore (10.25.0): - FirebaseCoreInternal (~> 10.0) - GoogleUtilities/Environment (~> 7.12) - GoogleUtilities/Logger (~> 7.12) - FirebaseCoreExtension (10.25.0): - FirebaseCore (~> 10.0) - FirebaseCoreInternal (10.25.0): - "GoogleUtilities/NSData+zlib (~> 7.8)" - FirebaseCrashlytics (10.25.0): - FirebaseCore (~> 10.5) - FirebaseInstallations (~> 10.0) - FirebaseRemoteConfigInterop (~> 10.23) - FirebaseSessions (~> 10.5) - GoogleDataTransport (~> 9.2) - GoogleUtilities/Environment (~> 7.8) - nanopb (< 2.30911.0, >= 2.30908.0) - PromisesObjC (~> 2.1) - FirebaseInstallations (10.25.0): - FirebaseCore (~> 10.0) - GoogleUtilities/Environment (~> 7.8) - GoogleUtilities/UserDefaults (~> 7.8) - PromisesObjC (~> 2.1) - FirebaseMessaging (10.25.0): - FirebaseCore (~> 10.0) - FirebaseInstallations (~> 10.0) - GoogleDataTransport (~> 9.3) - GoogleUtilities/AppDelegateSwizzler (~> 7.8) - GoogleUtilities/Environment (~> 7.8) - GoogleUtilities/Reachability (~> 7.8) - GoogleUtilities/UserDefaults (~> 7.8) - nanopb (< 2.30911.0, >= 2.30908.0) - FirebaseRemoteConfigInterop (10.25.0) - FirebaseSessions (10.25.0): - FirebaseCore (~> 10.5) - FirebaseCoreExtension (~> 10.0) - FirebaseInstallations (~> 10.0) - GoogleDataTransport (~> 9.2) - GoogleUtilities/Environment (~> 7.13) - GoogleUtilities/UserDefaults (~> 7.13) - nanopb (< 2.30911.0, >= 2.30908.0) - PromisesSwift (~> 2.1) - FLAnimatedImage (1.0.17) - FLEX (5.22.10) - GoogleAppMeasurement (10.25.0): - GoogleAppMeasurement/AdIdSupport (= 10.25.0) - GoogleUtilities/AppDelegateSwizzler (~> 7.11) - GoogleUtilities/MethodSwizzler (~> 7.11) - GoogleUtilities/Network (~> 7.11) - "GoogleUtilities/NSData+zlib (~> 7.11)" - nanopb (< 2.30911.0, >= 2.30908.0) - GoogleAppMeasurement/AdIdSupport (10.25.0): - GoogleAppMeasurement/WithoutAdIdSupport (= 10.25.0) - GoogleUtilities/AppDelegateSwizzler (~> 7.11) - GoogleUtilities/MethodSwizzler (~> 7.11) - GoogleUtilities/Network (~> 7.11) - "GoogleUtilities/NSData+zlib (~> 7.11)" - nanopb (< 2.30911.0, >= 2.30908.0) - GoogleAppMeasurement/WithoutAdIdSupport (10.25.0): - GoogleUtilities/AppDelegateSwizzler (~> 7.11) - GoogleUtilities/MethodSwizzler (~> 7.11) - GoogleUtilities/Network (~> 7.11) - "GoogleUtilities/NSData+zlib (~> 7.11)" - nanopb (< 2.30911.0, >= 2.30908.0) - GoogleDataTransport (9.4.1): - GoogleUtilities/Environment (~> 7.7) - nanopb (< 2.30911.0, >= 2.30908.0) - PromisesObjC (< 3.0, >= 1.2) - GoogleMaps (7.4.0): - GoogleMaps/Maps (= 7.4.0) - GoogleMaps/Base (7.4.0) - GoogleMaps/Maps (7.4.0): - GoogleMaps/Base - GoogleUtilities/AppDelegateSwizzler (7.13.3): - GoogleUtilities/Environment - GoogleUtilities/Logger - GoogleUtilities/Network - GoogleUtilities/Privacy - GoogleUtilities/Environment (7.13.3): - GoogleUtilities/Privacy - PromisesObjC (< 3.0, >= 1.2) - GoogleUtilities/Logger (7.13.3): - GoogleUtilities/Environment - GoogleUtilities/Privacy - GoogleUtilities/MethodSwizzler (7.13.3): - GoogleUtilities/Logger - GoogleUtilities/Privacy - GoogleUtilities/Network (7.13.3): - GoogleUtilities/Logger - "GoogleUtilities/NSData+zlib" - GoogleUtilities/Privacy - GoogleUtilities/Reachability - "GoogleUtilities/NSData+zlib (7.13.3)": - GoogleUtilities/Privacy - GoogleUtilities/Privacy (7.13.3) - GoogleUtilities/Reachability (7.13.3): - GoogleUtilities/Logger - GoogleUtilities/Privacy - GoogleUtilities/UserDefaults (7.13.3): - GoogleUtilities/Logger - GoogleUtilities/Privacy - nanopb (2.30910.0): - nanopb/decode (= 2.30910.0) - nanopb/encode (= 2.30910.0) - nanopb/decode (2.30910.0) - nanopb/encode (2.30910.0) - PromisesObjC (2.4.0) - PromisesSwift (2.4.0): - PromisesObjC (= 2.4.0) DEPENDENCIES: - FirebaseAnalytics - FirebaseCore - FirebaseCrashlytics - FirebaseMessaging - FLAnimatedImage (~> 1.0) - FLEX - GoogleMaps SPEC REPOS: https://github.com/CocoaPods/Specs.git: - FirebaseAnalytics - FirebaseCore - FirebaseCoreExtension - FirebaseCoreInternal - FirebaseCrashlytics - FirebaseInstallations - FirebaseMessaging - FirebaseRemoteConfigInterop - FirebaseSessions - FLAnimatedImage - FLEX - GoogleAppMeasurement - GoogleDataTransport - GoogleMaps - GoogleUtilities - nanopb - PromisesObjC - PromisesSwift SPEC CHECKSUMS: FirebaseAnalytics: ec00fe8b93b41dc6fe4a28784b8e51da0647a248 FirebaseCore: 7ec4d0484817f12c3373955bc87762d96842d483 FirebaseCoreExtension: 8a47811d0b155501559ef05d089518152a0a1677 FirebaseCoreInternal: 910a81992c33715fec9263ca7381d59ab3a750b7 FirebaseCrashlytics: 4b96efb0ce73b38b2a85e8b8bd1bd8f63f09d015 FirebaseInstallations: 91950fe859846fff0fbd296180909dd273103b09 FirebaseMessaging: 88950ba9485052891ebe26f6c43a52bb62248952 FirebaseRemoteConfigInterop: b25018791b204c0d78a90e394d6c62d9b1f22da8 FirebaseSessions: c0939656253a1fa0e94ecc266ccf770cc8b33732 FLAnimatedImage: bbf914596368867157cc71b38a8ec834b3eeb32b FLEX: f21ee4f498eed3f8a1eded66b21939fd3b7a22ce GoogleAppMeasurement: 9abf64b682732fed36da827aa2a68f0221fd2356 GoogleDataTransport: 6c09b596d841063d76d4288cc2d2f42cc36e1e2a GoogleMaps: 032f676450ba0779bd8ce16840690915f84e57ac GoogleUtilities: ea963c370a38a8069cc5f7ba4ca849a60b6d7d15 nanopb: 438bc412db1928dac798aa6fd75726007be04262 PromisesObjC: f5707f49cb48b9636751c5b2e7d227e43fba9f47 PromisesSwift: 9d77319bbe72ebf6d872900551f7eeba9bce2851 PODFILE CHECKSUM: 42c53e4a392cb267d7a102308db901173ee5a9df COCOAPODS: 1.15.2 ```