Unexpected behavior when refreshing token of a user who is the unique member of a device group

Question

I implemented the mapping between devices, registration ids, and groups as explained here

Basically came up with a table where to store the device reg id and the notification key of the group to which it is registered (if any) , and added to my user table two fields to keep track of the number of devices that user has logged into and what is his pre determined group name.

Unfortunately, while testing, I incurred into a very strange behavior when refreshing the token of a user, who is also the only member of a device group.

as explained in the comments to the question i asked here

if the previous token was the only member of a device group, after getting refreshed it is invalidated but the group keeps existing and somehow the new token gets added to it. i can even successfully remove the new token from the group thus deleting it, or i can notify the group "waking it up" and making it to auto remove itself

in the couple of tries i have done right now before posting this is what happened:

1. get a new token say reg_id1
2. register reg_id1 to device group test_group (creating it)

code to create group:

curl --header "Authorization: your_key" 
--header Content-Type:"application/json" 
-H "project_id:your_id"   https://android.googleapis.com/gcm/notification 
-d "{ \"operation\": \"create\", \"notification_key_name\": 
\"test_group\", \"registration_ids\": [\"reg_id1\" ] }"

3. test that the group exists

with this

curl -v -H "Content-Type:application/json" -H "Authorization:key=your_key" 
-H "project_id:your_id"
https://android.googleapis.com/gcm/notification?notification_key_name=test_group

4. refresh reg_id1 with the way you prefer (deleting app data if on android or requesting new token if on web app )
5. check what happened to the group with the command at point 3

the group still exists (even if the only token there is now invalid)

6. try deleting old token. what should happen? well, the answer is reasonable..the token we are trying to remove is not valid anymore

code to remove

curl --header "Authorization: key=your_key" 
--header Content-Type:"application/json" -H "project_id:your_id" 
https://android.googleapis.com/gcm/notification 
-d "{ \"operation\": \"remove\", \"notification_key_name\": 
\"test_group\", \"notification_key\": \"group_key\", 
\"registration_ids\": [\"reg_id1\" ] }"

7. Here comes the fun: try deleting the new refreshed token from the same group ! you will get a notification key in return , meaning that there were no errors..but wait ! how could it be?
8. ping the group again with command at point 3 and.. the group still exists?! (previously, at the time of the problem in original question, while removing the new token from android, the group would cease to exist after this point..now with curl it continues living)
9. try notifying the group then!

code

curl -X POST -H "your_key" 
-H "Content-Type: application/json" 
-d '{ 
"notification": {
 "title": "Portugal vs. Denmark",
 "body": "5 to 1",
 "icon": "firebase-logo.png",
 "click_action": "http://localhost:8081"
},
"to": "group_key"
}' "https://fcm.googleapis.com/fcm/send"

10. what happens now is that you get 1 failure (which is ok) and if you try to ping the group again it will be magically disappeared..

Sorry for being so long but i wanted to write all the steps so that you can reproduce the behavior easily.

Can someone explain all of this? In my android app if the user deletes app data he will need to login again, since the creation/add to a device group is upon login, i need to delete the old token from the group (and delete the group if it was the last) so that he will be able to re-enter the group again (or create it). But i can't remove the old token directly because it is invalid. still, the group continues existing even if its only member is invalid. should i just notify it to wake it up and make it delete itself? should i remove the new token from the group as well ? (in android this would strangely lead to deleting the group)

EDIT: after testing this morning i have a new use case:

1. Create group with reg_id1 subscribed to it
2. refresh reg_id1
3. recreation of group says that group exists ( i can ping it ad receive a notification key in response)
4. try to delete new token from group gives error 500
5. notification test to the group gives 0 success and 0 failure
6. try to remove old token from group gives back notification key (should be a positive answer)
7. now group doesn't exist anymore

EDIT2:

after lots and lots of testing i came to these conclusions:

• refreshing a token on android application invalidates it, if it was the only member of a device group, a simple notification to that group will wake it up and make it auto delete itself.
• refreshing a token on a web application does not invalidate the token, if it was the only member of a device group, notifying the group will result in a 0 success 0 failure. while being invisible the token is still registered to the group and the group will cease to exist only when the old token will be removed. in this case, even if still there the old token won't concur to the limit of 20 devices ( i successfully registered and refreshed 25 tokens to the same group). What is needed now is a way to retrieve the old token to remove it from the group , in a web application scenario. this is crucial since a web application doesn't have a unique id therefore it can't be mapped as in android (with the android id) to the registration token, and the old token won't even appear as a failure when notifying, meaning that it's almost impossible to retrieve it after it was refreshed.

Answer 1

This is what i ended up doing. it's by no means elegant, and i had to compromise between what i need and what actually happens.

First of all i confirm that:

1. In android , when a token gets refreshed it is invalidated, therefore automatically eliminated from every group it was part of (not instantaneously, more like at the first notification or operation of add/removal on the group). This is why a simple notification (not dry_run though) would serve as wake up for the group, meaning that if it was the last member, the group would immediately die. Notice that even if the token gets invalidated, in the case it was the last member of the group, the group continues to exist! a notification would wake it up and kill it, but otherwise adding more devices would still work!

2. On a webapp instead, the behavior is much more complex because it is browser dependent (surprise?). for example in Firefox the refreshed token magically disappears, but doesn't get invalidated. meaning that if it was the only member of a group, sending a notification to that group will result in 0 success and 0 failures, only after removing that old token from the group, the group will get deleted. Subsequent adding or removal would all work, but if you didn't remove the old token, once empty the group would not delete itself and return again 0 success - 0 failures. In chrome instead, the behavior is like in android (token invalidated etc. ).

Since i needed something working for both android and web app i thought about differentiating the web behavior by keeping track of the token upon login , putting it in a table (user_id, reg_id). at every login i would check if every token associated with the user was still valid (sending a notification to it and looking at the failures) and in case, delete it from the user group whose group name and group key i would retrieve from my user table. This would have greatly worked, making it possible to remove ghost tokens from groups , if not for the fact that in chrome the tokens get invalidated when refreshed (android-like), meaning that sending a notification would return a failure but with different error ("invalid registration id" instead of " not registered" or something like that). I could have further specified my functions to do their work with respect to the browser they were in , or maybe just check the error type and understand if i had to delete it from the group because it was a ghost token or just delete the line from my db because it had been invalidated. Well, at that point i was really fed up with the poor management api of firebase's groups, therefore i chose the simplest solution: do nothing.

I concocted a powerful function, to be executed after login , that would take care of pinging a group by its name (as explained in the question's cURL commands) and either create the group if error or add to the group if a notification key was returned. Mind that one could even directly try to create the group, and in case of error just add the device to it, same thing.

the refresh of a token would fall in those two scenarios (invalidated or ghost), meaning that the worst that could happen is the group not dying when the last member exited, too bad. ghost tokens shouldn't add up to the limit of devices per group.

Sad, but easy and working. If anyone can see any downside to doing as described, i would love to hear about it.