Re: [w3c/ServiceWorker] Service Workers are too hard to clean-up (Issue #1695)

There was some long-running discussion of this issue in https://github.com/w3c/ServiceWorker/issues/204 where https://github.com/w3c/ServiceWorker/issues/204#issuecomment-342658175 is the most recent decision that was made as a result of a F2F discussion.

The documented decision there was made on the basis of 2 very large sites having occasional transient problems where it would be undesirable to unregister the ServiceWorker due to a configuration hiccup that served a 4xx response, but the concern does seem universal.  I think that's compatible with the observation on this issue that persistent 4xx responses do happen and are reasonable to handle.  Clear-site-data [has been mentioned in this context](https://github.com/w3c/ServiceWorker/issues/204#issuecomment-342658175) and is useful for sites that still exist, but it's still a big hammer[1] and not an option for expired domains, etc.

If we were to spec a solution to this, we could potentially do something like:
- Each registration would maintain a "failed update count" that is incremented whenever we perform an update check and the registration was [stale](https://w3c.github.io/ServiceWorker/#service-worker-registration-stale) or some other mechanism to ensure we only increment the counter at most once a day.
- If the counter reaches a threshold, we unregister the registration.  This may trigger cleanup for things associated with the registration, but would not touch the default bucket.  (Or the storage bucket the SW is associated with; the semantics described in the buckets explain's [Storage buckets and service workers section](https://wicg.github.io/storage-buckets/explainer#storage-buckets-and-service-workers) only defines a relationship to clear the SW when clearing the data, not the reverse, although honestly that could be nice.  But at least if the registrations were removed due to no longer existing, that would make the bucket more subject to data clearing for lack of use.
- We could optionally let sites specify the desired number of failed updates before removal, but would have a default if not specified, allowing existing stale registrations to be removed by the spec and without requiring opt-in.  I think it would be reasonable to also establish an upper bound on this value, although I would not be shocked to find there are people who would like to enable [sneakernet](https://en.wikipedia.org/wiki/Sneakernet)-type use cases where the SW only updates on private networks and is otherwise inaccessible.  (Although that raises questions of how such an origin could be a secure context.)

1: In particular, there isn't a way to express "clear the site data if the user's last visit/data mutation is older than date Y when we overhauled the site.  It had [been proposed in passing](https://github.com/w3c/webappsec-clear-site-data/issues/33#issuecomment-327801864) but there is nothing in the [storage spec](https://storage.spec.whatwg.org/) at this time to enable such functionality.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1695#issuecomment-1992363212
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1695/1992363212@github.com>