Force serviceWorker update when existing "bad" serviceWorker is active and cache first

Question

I have a problem, much like this question, which is a few years old now.

The problem I have is [a] new JS to the app code to unregister the ServiceWorker or skip-waiting is not being parsed because the app code is being served by the old ServiceWorker, and [b] I have full control of the server, but using the Clear-Site-Data: response header isn't working because all of the app's files are being served from the ServiceWorker or cache. It's never seeing that header. The only fresh requests are being made to an API on a different subdomain.

There are users out in the world using this application. What can I do to get clients with the old serviceWorker installed and running in their browser to observe new updates?

Answer 1

The request for the underlying service worker script file during an update check should always bypass both the HTTP cache and the existing service worker's fetch handler.

You should be able to add the Clear-Site-Data: header to the response for the underlying service worker script file returned by your web server and recover in that manner.

Additionally, you should be able to include code in the service worker script file along the lines of what's in that "kill switch" example and it will be run whenever a browser makes an update check, since again, that update check will bypass caches and go against the web server.