FCM & Old Tokens

[Kyle Brock]

We're seeing something that we're not expecting to see regarding FCM and what we perceive as older tokens.

The situation manifests itself as a user getting two push notifications when they should only be getting one.

This could be a misunderstanding we have with how push works.  So, any clarification on what we're doing vs what we should be doing would be very much appreciated.

What we're typically doing:

1. User installs device, we send the FCM/GCM registration id to our API.  

     a. When a user logs in we attach the user ID to that token.

     b. When a token changes (via instance ID API) we add a new token and unregister (delete) the old token (why I said typically, in production we're always unregistering.  But, we didn't for a bit in a beta.  That was a mistake.  We're about to starting doing so again).

2. When a push needs to be sent (because something happened... data was created, etc)

     a. We find the appropriate tokens from our API and send a push

     b. If we get an InvalidRegistration or NotRegistered error code, we delete our copy of the token(s).

     c. If we get a canonical ID, we replace our ID(s) with the canonicalized version (the IDs are the unique key in our data store). 

What we're seeing is that there are tokens that are several years old that never go passed the Accepted state.  So, it seems that these tokens should be returning NotRegistered or InvalidRegistration.  Maybe they wouldn't, but, this user has gotten several new tokens in the meantime.  I can imagine that they are from old devices.  But, I would think with the age of the tokens they should be invalid or not registered any more.  Still, this isn't that important (though, if they aren't ever going to be sent, it would be nice to know we don't need these records).

The most interesting part is that we have two tokens that are being accepted and delivered to the device for the same user on that device.  And, we're not getting canonical IDs that inform us we should only be using one ID.  This is why the user is getting two push notifications.  Admittedly, it's because of a mistake on our part in not discarding the other token when we got a new one.  But, I would think the older one would get canonicalized (and it's not).  Is this not how things should work?  Or are we missing something?

Thanks!

[Liam Byrne]

I don't recommend using the FCM token as an identifier for an app instance as these can change. I'd suggest generating your own fixed identifier, or you can use FirebaseInstanceId.getId() which is only reset if the app's data is cleared or the app is uninstalled/reinstalled.

FCM doesn't return a canonical token for sends to tokens generated by either FirebaseInstanceId or the older InstanceID APIs as an app instance can have multiple tokens so it wouldn't be clear which to return.

To deal with your problem of having multiple tokens for the same app instance, you can try deduping by looking at the part before the colon of your tokens (will be same as FirebaseInstanceId.getId()), the current format is <ID>:<rest of token>. If two tokens have the same ID they will be for the same app instance. Older tokens generated by calling GoogleCloudMessaging.register() won't have this prefix so can't be deduped in this way.