Stream: subscriptions
Topic: Appropriate way to manage subscriptions
Brian Reinhold (Sep 23 2019 at 22:57):
On the page describing the Subscription resource it states that the client should delete the Subscription when it is done. I am not 100% sure how I should interpret that. If I have an app that subscribes to something, does that mean when the app quits, I shall delete the subscription, or is that only the case when the app will never restart? The app could update the subscription to turn it from active to off, save the subscription logical id, exit, and on restart update the subscription to make it active (or requested, if active is not allowed to be set by the client).
What is the exact procedure?
Jenni Syed (Sep 24 2019 at 14:17):
Interesting. In connectathons, we've had the client set it to off - not delete. @Brian Reinhold That type of behavior may depend on the app. In the spec, it calls out that the server may set it to off if it fails to deliver too many times as well. If the endpoint to notify goes away when a specific instance of the app is closed, you would likely want to control the lifecycle on the app side (otherwise you'll have to check if the server shut it off anyway due to errors)
Jenni Syed (Sep 24 2019 at 14:18):
Most of the apps in the tests have been server side that can then deliver to specific instances - so the server was always there.
Gino Canessa (Sep 24 2019 at 15:06):
That text was added in an effort to reduce orphaned subscriptions. If a client will no longer need notifications (e.g., the user is removing an account, the app is being removed, etc.), it should remove the subscription. This is probably just wishful thinking, as apps will likely be deleted without being given the opportunity.
In the case that the app will just be offline (and the endpoint will either be offline or cannot queue messages for the client), then setting to off would be more appropriate since the app will want to re-enable it when it comes alive again.
We have not discussed the fine-grained process for re-enabling a subscription which is off. I can see arguments for either status (requested or active directly). Do server implementers have a preference?
Grahame Grieve (Sep 24 2019 at 22:00):
servers should probably clean out subscriptions over time. Especially app added ones, though I'm not sure how that differentiation would be made
Gino Canessa (Sep 24 2019 at 22:06):
There is an end (instant) field which should be filled out (and extended if needed). It is optional, but I can see servers requiring it for that reason.
Josh Mandel (Sep 25 2019 at 20:10):
In the Argonaut encounters IG (for instance), we've discussed wherever we should require clients to set an end date (and requiring that it be no more than xx months in the future).
Pascal Pfiffner (Sep 27 2019 at 21:31):
I like that idea of an end date. (A)live apps can just update the date as they periodically check their subscriptions' statuses.
Keith Boone (Oct 11 2019 at 14:01):
We use end date for that reason in current implementations, and default it if not set via a business rule. There's a process that cleans them out periodically based on end date.
Last updated: Apr 12 2022 at 19:14 UTC
