Multiple Notifications for Named Users

Follow

Hi Mark,

I did some research for the push you mentioned, and I wanted to report some findings to see if that helps clear up anything.

For the Push ID you mentioned (81f3527d-c4c0-4a34-b0af-cc0ffa387096), I see two devices that were sent to via APNS:

Channel ID: 81e2a8f6-30fe-46e3-bf14-015f50024445

Channel ID: 4814600e-36d0-49b3-991d-ba99486f98ca

Those were the only two iOS devices were able to find that a push was sent off to APNS to be delivered.

However, when I look at the actual Device Token that was sent to, I find (at least for the first device) the Device Token was: 

E9AB1F18D2873D189F69BAD914889C1634AA93700AF2E810E9DC6BBD47344D4

Now, I also did take a look at that same Channel ID to look at the device token, and I find that the Device Token has changed to:

A90D325DCC4CB8F74F40279138277596A0FB3A47358E343880D4C7D378662BAA

When the Device Token changes like that, that could usually indicate one of several things:

1. Resetting the keychain on iOS

2. Restoring the iOS device from an iTunes back-up

3. Uninstall, reinstall app after 24-hour period of time.

If you're resetting the keychain at all, that's usually the first culprit that is the cause of the issue. If so, it should be pretty easy to resolve so it's only clearing the keychain for the appropriate items.

For restoring the iOS device from an iTunes back-up, usually this results in an old Device Token being associated to the device, as well as the "new" Device Token being associated to it as well. Generally, a manual deactivation of the unused Device Token would be necessary to clean it up.

For the uninstall/reinstall, this is a pretty common occurrence. Generally what happens is the device uninstalls the app, and then reinstalls the app and manages to get a new Device Token.

However, if a push is not sent inbetween the uninstall and reinstall event, that Device Token could still be marked as active and still pushable in Apple's system. In this case, it's up to Apple to determine what push and how many to send to a specific device.

A good way to prevent this from happening during testing is to send a push to the old Device Token to ensure that that Device Token is marked as uninstalled in Apple's system, and subsequently Urban Airship. This should prevent the issue from occurring again.

As for fixing the issue as it stands right now, you may try directly sending a push to the old Device Token to see if that will clear that association on Apple's side. 

Thanks for the info. I'll look into your info and suggestions

Hi Michael

In this particular case we are 100% dealing with scenario 3 as we are testing our app and notifications and the app is being updated via Testflight on average once a week.

I'm glad you used Channel ID 81e2a8f6-30fe-46e3-bf14-015f50024445 as an example as its my own test phone.

I also understand that part of this issue is of Apples making which is why we went with a 3rd party push provider to get some level of abstraction from dealing with Apple directly.

Your suggestions while helpful in some ways, fail to resolve the issue in that :-

A. We cant query the push_id that we generate to find all the device tokens Apple sent notifications too. We can only query your own Push Report API which gives us a high level 'sends' number.

B. You mention that sending a push notification to one of the 'old' device tokens might help mark the token as stale. Isn't that's what's happening already when we send out our notifications? Apple should recognise that 2 of the 3 tokens it's sending notifications to are actually invalid and mark then as inactive?

In that regard I'm still failing to see why my phone gets 3 notifications as only one token is active

Please correct me if I am wrong in the below process which I believe is how its being pulled together

1. We tag a number of named users with a tag of our choosing

2. We generate a group push to all devices that have the tag assigned to them and the subsequent push report confirms our expected result of the number of 'sends'

3. UA most likely then take the device token of any channel_id that contains a matching tag we generated the push for and send Apple the required APNS requests. I can only assume that UA requests a push notification to the stored device token (in this case my current device token of A90D325DCC4CB8F74F40279138277596A0FB3A47358E343880D4C7D378662BAA)

If thats the case why does Apple then decide to send a notification to E9AB1F18D2873D189F69BAD914889C1634AA93700AF2E810E9DC6BBD47344D4 and why doesn't Apple mark it as invalid when my app is installed and has received the newer device token from them.

If my assumption is correct and UA sends a notification to a single device token then how does apple magically turn that into 3 pushes when your push should only contain the single valid device token of the channel that contained the tag?

If however UA in fact sent the push to device token E9AB1F18D2873D189F69BAD914889C1634AA93700AF2E810E9DC6BBD47344D4 then that IMHO is a bug on your side as we simply don't have that device token listed in any of our device apps when we look at the device tokens in the dashboard.

In any case I pushed a notification directly to the old device token E9AB1F18D2873D189F69BAD914889C1634AA93700AF2E810E9DC6BBD47344D4 and the push id of that operation a8ea25c5-4909-43a0-a394-a98ced627eaa returns 0 sends when I query it so I'm hoping that device token is now dead and buried. Time will tell when our next test run occurs

In the meantime I guess I'm most interested in my points regarding the above and if in fact UA sends a push to the current and correct device token then how and why do Apple decide that other tokens are needing to be involved (incorrectly). Surely UA sends a push to the current device token (which is correct) so why is Apple sending to others?

If however UA is deciding to send a push to the old device token then why?

Update - Ran our notification tests and my phone got one notification. My phone is currently acting as another named_user id than the tests so I'm assuming that 

the direct send I did to E9AB1F18D2873D189F69BAD914889C1634AA93700AF2E810E9DC6BBD47344D4 possibly cleared the device token.

The push_id for the test was 3882716e-5853-4cac-9a03-3d096dd903d3.

It will be interesting to see what device tokens UA or Apple decided to send the notify to and why....

My phones device token A90D325DCC4CB8F74F40279138277596A0FB3A47358E343880D4C7D378662BAA now has named user 'SIM-1498010159-8-dev-nibbl' which is why I think I did not get 2 notifications as a result of the test run.

1 - one of my stale token was deleted, 2 - my phone now is associated with another named user id and 3 - there is one another stray/old device token floating around which is why I was getting 3 notifications on each test run

Either way I'm still VERY interested in how and why UA/Apple decides to use these stale device tokens when in theory we are requesting a push to 

I just ran a few manual tests.

If I perform a direct push to my ios_channel or device token then I get a single notification in each instance

Its also interesting that now that my previous named user id doesn't have a channel associated to it that the push report from a test run still shows 2 'sends'

push_id = b4899351-d1d5-44d0-a566-15c650a8a734

for that push only one of the 2 named_user ids has a channel as my previous one although tagged is not associated with a channel now as expected

{
"ok": true,
"named_user": {
"named_user_id": "mark-1500855428-1-test-nibbl",
"tags": {
"aws": [
"chem_alert"
]
},
"created": "2017-09-10T23:45:42",
"last_modified": "2017-10-24T00:03:54",
"channels": []
}
}

Mark,

To answer your question regarding the Device Token issue, Urban Airship can't know if a Device Token is invalid on Apple's end if Apple does not send us that feedback.

So, if we have this scenario:

1. Device A installs app

2. Device A is associated to Device Token 1234.

3. Device A uninstalls app

4. Device A reinstalls app

5. Device A is associated to Device Token 5678.

In this scenario, the Device Token 1234 is still active, according to Apple. Apple only ever provides feedback that that Device Token was uninstalled if and only if a push is sent to that device. That feedback is also how Urban Airship knows that that Device Token was uninstalled. If Apple never sends us that feedback, then Urban Airship will not know the state of that device. In our system as well, it's still a valid device.

If that push is never sent to the device, then Apple still treats that as a deliverable device. I can't say for certain how Apple's database stores this information, but you can presume that both Device Token 1234 and Device Token 5678 are linked to the same device. In the Urban Airship side, Device Token 5678 is treated as a separate device, as is Device Token 1234. It's only on Apple's side that those two tokens are linked to each other.

A good way to test would be to run through the same situation of uninstalling and reinstalling the app on your device, only in between the uninstall and reinstall, send a push to the old Device Token/Channel Id such that Apple indicates that that device in uninstalled and sends that feedback to Urban Airship.

Then, when your device is assigned a new Device Token, that Device Token should not be linked to the old Device Token.

Hey thanks for the clarification. It helped a lot

Going to work thru this app deletion and push workaround and see how it pans out

Best Regards