fcmToken not revoked after calling deleteIDWithHandler

[wangjiejacques]

[REQUIRED] Step 2: Describe your environment

• Xcode version: 11.2.1
• Firebase SDK version: 6.13.0
• Firebase Component: Messaging
• Component version: 4.1.9

[REQUIRED] Step 3: Describe the problem

My app can still receive notification after calling InstanceID.instanceID().deleteID.

Steps to reproduce:

1. register fcm token by InstanceID.instanceID().instanceID.
2. revoke fcm token by InstanceID.instanceID().deleteID.
3. send notification by the revoked fcm token.
   expected behavior: the fcm token should be revoked, so the device should not receive notification.
   actual behavior: the device can still receive notification.

What happened? How can we make the problem occur?
send notification after calling InstanceID.instanceID().deleteID

Relevant Code:

- (void)deleteIDWithHandler:(FIRInstanceIDDeleteHandler)handler NS_SWIFT_NAME(deleteID(handler:));

[rizafran]

Hi @wangjiejacques, thanks for reporting. May I know if you're sending notifications via user segment, topic or token?

[wangjiejacques]

Hi, @rizafran via token.
FYI, my App is available on Android and iOS, when I call deleteId on Android, it works, the fcmToken is revoked.

[tommy-hartz]

+1, I am experiencing this same issue. I tried reverting to an older SDK version (5.7.0) but the issue still occurs there.

Interestingly, I can see from the app logs in Xcode that after calling deleteIDWithHandler my app does delete it, and then registers a new FCM token. However, server side the FCM endpoint still thinks the older token exists, and sends pushes to my device.
POST https://fcm.googleapis.com/fcm/send

{ 
    "registration_ids": [
    	"<deleted_token_here>"
    	],
...

Response

{
    "multicast_id": 8523650395121919828,
    "success": 1,
    "failure": 0,
    "canonical_ids": 0,
    "results": [
        {
            "message_id": "1575304153434673"
        }
    ]
}

If I wait long enough then eventually, I do start getting "NotRegistered" responses:

{
    "multicast_id": 5763468700354600408,
    "success": 0,
    "failure": 1,
    "canonical_ids": 0,
    "results": [
        {
            "error": "NotRegistered"
        }
    ]
}

The window of time seems to vary randomly, I've seen it take up to an hour to recognize the token was deleted. In the meantime, it keeps showing push notifications on my device even though the message was sent with the deleted token.

[andirayo]

As far as I know, the call to InstanceID.instanceID().deleteID triggers a Firebase-wide deletion flow of data associated with the given Instance/Instance-ID. This flow deletes all data that is stored by Firebase applications associated with the app-install identified by that Instance-ID, including FCM tokens, notifications, remote configurations, predictions, A/B tests, targeting-audiences, and so on.
For FCM-tokens, like for any other data type, this process might be triggered immediately, but take up to 1 day depending on the server-state. Afaik, the entire deletion flow is guaranteed to complete within 30 days, under normal operation takes no longer than 1 day, and in optimal circumstances can happen immediately.

[tommy-hartz]

OK good to know. I'm using a hybrid app plugin (ionic). The equivalent android code:

FirebaseInstanceId.getInstance().deleteInstanceId();

FWIW I've not observed any delay whatsoever on Android, only iOS has been showing this delay behavior for token deletes recently.

My understanding from @andirayo now is this is working as designed in the client SDK, and simply deleting an FCM token is not a reliable way to immediately shut off notifications for a device.

The fix (for me) would be to implement a custom logout API endpoint. Delete the tokens from our custom notification server, not just the client app.

However, this still poses problems for the use case where a user logs out of my app while offline, then closes the app. I have no way of detecting the token was deleted from my backend, it will still send notifications to that device. @andirayo any advice for handling this scenario?

[charlotteliang]

@wangjiejacques @tommy-hartz This is expected as you didn't turn off auto init enabled flag.
You need to set FIRMessaging.autoInitEnabled = NO and stop calling getToken call in all your code so that the auto generation is stopped as well as no new token request is triggered.
For your case a new token is generated which is why push notification still works.

[tommy-hartz]

@chliangGoogle actually I have tried disabling the auto init, when doing so it does NOT automatically create a new token as expected. However when doing so, I still see the same behavior with the deleted token still "working" for some time, giving "success" responses from FCM push endpoint, and notifications displaying on device, even without a new instance id / token being registered by the device. Again, after some time I do get "NotRegistered" responses and no push delivered.

The issue here is more so with the (unexpected) delay on deleting the instance ID and tokens I think. It doesn't seem to matter whether I leave auto init enabled or not.

[charlotteliang]

@wangjiejacques Can you also confirm this is expected behavior so we can move one issue off the list.
@tommy-hartz As @andirayo stated, there might be a delay no more than 1 day. For your case, can you persist the state on device if user has log out offline, and when device gets back online and kicks off a new request to your backend to unreigster the token?

[wangjiejacques]

Hi @chliangGoogle , I'm OK with the auto init, I think this is what I want.
The problem is the revoked fcm token(not the new one generated by auto init) still works for iOS,
In contrast, deleteInstanceId in the Android sdk works very well.

[charlotteliang]

@wangjiejacques as @andirayo stated, there is a delay that old token still takes effect but should no more than 1 day. Is that the same experience you see?

@andirayo I wonder why android has no such delay.

[wangjiejacques]

@chliangGoogle Thanks, for the Android, since I only tested it once, I'm not sure if it is always the case.

I will do the test to see if this is true for both Android and iOS.

[charlotteliang]

That would be very helpful. Thank you!

[andirayo]

I looked through the code-paths:
a) FCM-Registrations and Topic-Subscriptions are handled differently to other Firebase data: Firebase tries to delete those entries immediately (async), which explains why FCM-Tokens usually should stop working instantly.
b) When it comes to immediate deletions, both Android and iOS deletions should behave the same.

The only thing that I could come up with is that maybe the actual requests from client-side look differently for Android IID-SDK and iOS IID-SDK which could explain a difference in available data server-side, which in turn could lead to the Android code path being able to immediately detect and invalidate all FCM-Tokens, while the iOS code path might be missing information to do that and has to wait for the next run of the Firebase / FCM deletion job.

[wangjiejacques]

@chliangGoogle I confirm that
the iOS SDK doesn't invalidate the FCM-Token even after more than one day,
the Android SDK do invalidate the FCM-Tokens immediately.

[charlotteliang]

@andirayo Looks like clients have different behaviors between android and iOS, is there something I can do to help you debug?

[google-oss-bot]

Hey @wangjiejacques. We need more information to resolve this issue but there hasn't been an update in 7 days. I'm marking the issue as stale and if there are no new updates in the next 3 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

[morganchen12]

afaik this issue hasn't been resolved yet and shouldn't auto-close.

[tommy-hartz]

@tommy-hartz As @andirayo stated, there might be a delay no more than 1 day. For your case, can you persist the state on device if user has log out offline, and when device gets back online and kicks off a new request to your backend to unreigster the token?

Yes, but that implies the user will still be getting notified until they launch my app again. Or it would require background code execution with network communication, which Apple is usually restrictive about. I am not comfortable adding that to my app.

Not sure it's possible, but the ideal solution for me would be an SDK update so that deleting tokens on iOS is immediately recognized by FCM the same way it does on Android. In the meantime, it's not a major issue for us. Most of our users are never logging out and deleting tokens anyway.

[morganchen12]

Hey all, sorry for the slow update here--can you try deleting the FCM data through the new Messaging API instead of through InstanceID and seeing if the old FCM token is invalidated within a day?

[charlotteliang]

@morganchen12 I think this might need a backend change.