[w3c/ServiceWorker] Service Workers are an abject failure (Issue #1695)

I have noticed an upwards trend in the number of websites that are broken for me due to service workers being published on them and then left to rot in my browser's caches. A while ago I ran a query on the status codes returned by over 400 service workers registered in my Edge browser and got the following HTTP response codes:

| HTTP Code | Count |
-- | --
no response | 8
200 | 336
301 | 15
302 | 2
400 | 5
403 | 17
404 | 29
418 | 1
500 | 1
502 | 1
504 | 1
Total | 416

51 out of 416 service workers registered in my browser are registered on locations that now return 4xx response codes [indicating the client made an error making the request](https://www.rfc-editor.org/rfc/rfc7231#section-6.5). The failure mode from leaving a stale service worker on a site ranges from giving stale data to the website being [completely inaccessible](https://github.com/sveltejs/sites/issues/465).

For example when I want to go buy tickets from my reginal train company [sj.no](https://www.sj.no/) I'm greeted by this

![image](https://github.com/w3c/ServiceWorker/assets/14362102/137f5e0a-ce99-4607-9d97-d26e4c18a638)

If you compare this to what the live site actually looks like you may notice it is very different. The ticket ordering does not work, and pretty much every page you can navigate to is not functional.

## Correctly removing Service Workers is far too difficult

Service workers once registered lives on indefinitely, and will not go away until explicitly removed. However removing them [is deceptively hard](https://medium.com/@nekrtemplar/self-destroying-serviceworker-73d62921d717). If you try to search for how to uninstall a service worker you'll get [stack overflow questions filled with wrong answers](https://stackoverflow.com/questions/33704791/how-do-i-uninstall-a-service-worker).

Just to illustrate how difficult it is, going back to my regional train provider sj.no they actually tried to remove their stale service worker by hosting a new at the same resources location as the old one that attempts to remove the old one.

```
// Content of https://www.sj.no/service-worker.js
// Deregister old PWAs
console.debug("Deregistering service workers...");
navigator.serviceWorker.getRegistrations().then(workers => {
    console.debug(workers);
    workers.forEach(worker => {
        console.debug("Deregistered service worker");
        worker.unregister();
    });
});
```
Unfortunately this was probably copied and pasted from misinformation and doesn't work. Edge throws the following error when it is loaded, and the old one is therefore never removed.
```
service-worker.js:3  Uncaught TypeError: Cannot read properties of undefined (reading 'getRegistrations')
    at service-worker.js:3:25
(anonymous) @ service-worker.js:3
```

It should not be this hard to remove a service worker. HTTP's 404 status code means the resource does not exist. What rationale does the Service Workers have to stay alive after the origin server says it no longer exists? How are HTTP server operators supposed to know that they can't remove a service worker, instead they need to replace it with a self destructing service worked _and host that forever_.

What if you take over a domain that previously hosted service workers. Are you supposed to just know that you need to configure your webserver to reply to all requests with a `Service-Worker` header present with a self destructing Service Worker?

Violating HTTP semantics for the sake of some sort of longevity that is now demonstrably breaking real world websites is not a good way for this to work. I see no sensible reason for why a Service Worker should keep on living if the origin server replies with a 4xx status code when it's updated. Similarly if during an update the newly fetched service worker throws an error during execution this should also be taken as a signal to remove the existing Server Worker.

## Diagnosing a broken Service Worker is impossible for an end user

Imagine you're an end user that has no idea what a Service Worker is and the webpage you need to interact with is broken due to a stale Service Worker. You reload the page. You Ctrl+Reload the page. You reboot your computer. You even reinstall your browser (which then behind the scenes reused your existing profile and caches). But no matter what you do the webpage seemingly just doesn't want to work or your computer.

You then contact support who also have no idea about Service Workers and they test the site on their end and it works fine, and despite going through a bunch of steps the website is still broken for you and support can't help you. Sure a competent web developer can say you can easily remove the service worker by right clicking on the web page, select inspect, go to the application pane, click on the Service workers section and then click on unregister. But what if you're on a phone or a tablet?

## Conclusion

The difficulty in correctly using Service Workers are leaving real word websites permanently broken in ways that are difficult for developers, site operators and end users to diagnose and correct. If not even Web Framework developers can get this right, (as is the case for svelte.dev) what hope does regular web developers have in getting it right?

Failing to properly implementing Service Workers should result in the browser removing the service worker rather than the website becoming inoperable. And removing a Service Worker should be as simple as removing the service worker script for the server. Requiring server operators to host a special self destructing service worker until the end of time in order for returning users to not end up with a permanently broken website is not an acceptable way for this technology to work.

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

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