Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Inactive push subscriptions should be removed #1295
Does Autopush adopt any strategy to remove inactive push subscriptions?
For example, suppose that a browser or device is abandoned and thus it will never connect again to Autopush. Do you mark the endpoints as "expired" after some time of inactivity? Or the endpoints will last forever?
Based on data collected in the following study (that I have published), it seems that some push services don't remove all inactive subscriptions and this will create a steady decrement of delivery rates over time:
Basically it seems that some unused subscriptions will last forever because:
What is the expected behavior?
What went wrong?
For desktop based notifications, autopush expires a given notification if a given User Agent Identifier (UAID) has not reconnected within two months or so. What actually happens is that we tender the record over to DynamoDB's Time To Live (TTL) system, and it's eventually cleaned up. There are some older records that don't have TTLs, or whose TTL is greater than the minimum clean up period TTL that DynamoDB enforces (24 months), and those don't get cleaned up.
For mobile users, it's a bit more complicated. We only ever see the remote client once, when it requests a new endpoint. We have to trust that when we send a new notification to the remote bridge system, it will notify us when a given user's subscription is no longer valid. When that happens, we clean up the record and return a 410.
We could sweep our data set and kill off legacy connections (old desktop subscriptions that are beyond the TTL), but we've determined it would be cost prohibitive for us to do so. We may revisit that decision in the future, but for now, it's just not in the budget.
And, again, mobile makes it hard because if you've got a very old, but active subscription, we'd prefer not killing it. One big reason is that if we kill the subscription on our side, there's no way for the remote client to know and recreate the subscription through us. (Again, we may revisit that in the future, but we don't currently have the resources to address it now.)
The data in your article pretty much confirms this, with that weird spike around 26 months or so. I'd expect that number to hold reasonably steady, since it consists of many "grandfathered" subscriptions.
I have absolutely no idea why you get those spikes every 6 months.
That is perfect.
So basically when you get 410 from the bridge, then you return 410 to the application server... it makes sense. Then probably the problem for Firefox on Android relies in FCM.
I have posted a suggestion for the standard that should solve these kind of issues: