Problem with service workers and stale code

[ncrawlins]

Sorry if there is something fundamental I'm missing in the docs, but I can't figure this out. When I build for production and push to the server, the service workers (or app cache maybe?) still serve old versions of the app when I navigate to the production site. If hit CTRL-F5 in Chrome to force refresh, I see the new version of the app, but if I then just hit F5, it will revert to the old version (served by the service workers, I guess?)

Is there something I need to be doing when pushing a new version of the app to production to let the service workers know they need to update their cache?

[gihrig]

All browsers listed below (Mac OS) run the app in off-line mode as expected. In my local environment, content updates with a new npm run start:production do not appear reliably in all running browsers.

Restarting the browser shows updated content in all browsers.

I'm on Mac OS 10.11.5
Chrome 51.0.2704 - Content not updated with Cmd-R >>> is updated after browser re-start.
FireFox 47.0.1 - Content not updated with Cmd-R >>> is updated after browser re-start.
Safari 9.1.1 - Content updated after Cmd-R (twice)

I don't know if there is a real solution, or if a solution is needed. But, in case restarting the browser is not desirable, in Chrome you can clear the cached content by:

1. Start react-boilerplate app with npm start
2. Open localhost:3000 (in Chrome)
3. Open Chrome dev tools > Resources tab
4. Delete all cached content under Local Storage, Session Storage, Application Cache, Cache Storage and Service Workers.
5. Close browser tab and stop server
6. npm run start:production

A browser restart, or this procedure, needs to be done every time you run a production build in your browser, and is a local workaround only. How much of a problem this is depends on how frequently you update your app, and how critical having the latest content is to your end users.

[ncrawlins]

It's not a problem in development, because service workers aren't running. It's only a problem when a new version is deployed to production. It is being served from IIS 8.5 running .net core.

Restarting chrome in windows does not fix it, I have to clear all cache or unregister the service workers using chrome://serviceworker-internals/

I have no problems clearing my cache, but right now we are getting active feedback from users that can't be expected to mess with browser settings, as basic as that may seem. They are getting a new version about once a week, sometimes more.

I was hoping there was some way to maybe put a setting in the OfflinePlugin config or somewhere. So that when i pushed a new build it would know to grab the new index.html.

But if that's just the way it's meant to work, then I guess I can just disable the offline stuff for now because they don't really need it, and the app is changing a lot.

[gihrig]

@mxstbr , anyone else, is there a production-ready solution to updating content in offline-first?

[mxstbr]

Oh my, that sounds horrible @ncrawlins! @NekR, any input here?

[NekR]

Okay, first of all, it's not that bad :-) Let me example you how ServiceWorker and AppCache update process works.

Browser fetches ServiceWorker file each time user navigates to your website. If new ServiceWorker is found, it's immediately running along side with current SW. This new SW gets only install event a this time, which allow it to prepare/cache assets of a new version. New SW doesn't start controlling pages until all tabs of your website are closed, this is by design in SW.

AppCache has slightly simpler update mechanism: it also downloads manifest.appcache on each navigation to your site (simplified) and if new AppCache is avaialable, browser installs new AppCache and removes old one. This means that on a next page refresh browser will load files from new AppCache.

I guess AppCache is a confusing root here--you just expect SW to have the same update process. You also mentioned Cmd/Ctrl+R, it doesn't updates or reloads new SW, it tells to browser to bypass currently controlling ServiceWorker. If you have only 1 tab opened, then this flow can update SW:

Refresh (downloads new SW) -> Ctrl/Cmd+Refresh (bypasses SW, now SW doesn't control any pages, new SW can be used) -> Refresh (load new SW)

This is how it works. Of course, there is a way to update SW/AppCache when you want, you are developer after all :-)

// offline-plugin config
// tell to it to generate events for SW

new OfflinePlugin({
  ServiceWorker: {
    events: true
  }
})

// client-side code

const runtime = require('offline-plugin/runtime');

runtime.install({
  onUpdating: () => {
    console.log('SW Event:', 'onUpdating');
  },
  onUpdateReady: () => {
    console.log('SW Event:', 'onUpdateReady');
    // Tells to new SW to take control immediately
    runtime.applyUpdate();
  },
  onUpdated: () => {
    console.log('SW Event:', 'onUpdated');
    // Reload the webpage to reload into new version
    window.location.reload();
  },

  onUpdateFailed: () => {
    console.log('SW Event:', 'onUpdateFailed');
  }
});

There are similar option for AppCache: AppCache: { events: true }, but I don't recommend using it unless you really need it. AppCache's events are buggy and unstable and some times may not fire at all.

Restarting chrome in windows does not fix it, I have to clear all cache or unregister the service workers using chrome://serviceworker-internals/

@ncrawlins are use sure about that, can you re-check one more time? Here is how to test:

1. Load your webpage
2. Build and deploy new version with something changed, add alert(1) for example
3. Reload the webpage
4. Close the tab of the webpage (make sure there is no more open tabs of this website)
5. Open that webpage again in a new tab
6. Let us know if you see alert(1)

Thanks.

[NekR]

Oh, and:

then I guess I can just disable the offline stuff for now because they don't really need it, and the app is changing a lot.

If you don't need it--then simply don't use it. But I should warn you that you cannot simply remove sw.js and AppCache files from your server. If you will do so, your users will have stale content forever (until manual cache clear). To stop using SW/AppCache you have to ship uninstall code.

[jakearchibald]

Here's a quick video where I run through the update cycle of a SW. https://twitter.com/jaffathecake/status/709011058938269696 - it's basically the same as Chrome's update model.

[mxstbr]

Woah thanks for that @NekR and @jakearchibald – we should add that great explanation to the docs!

[NekR]

@mxstbr Yeah, I think about it too. I'll it to offline-plugin docs. Feel free to add it to react-boilerplate too, if you think this will help :-)

[ncrawlins]

are use sure about that, can you re-check one more time? Here is how to test:

I must have been misremembering. I can't reproduce that. Seems to be working as you described.

[NekR]

So, is this still a bug then? @ncrawlins have you managed to make offline-plugin to work for you as you want?

@mxstbr maybe we should include SW events by default into boilerplate?

[ncrawlins]

yep, it is working for me. sorry for the initial misinformation about the behavior, but the explanation of how it all works was very helpful.

[NekR]

No problem, I am glad to help.

If something, here I wrote a doc based explanation here (same content, just reworded a bit): https://github.com/NekR/offline-plugin/blob/master/docs/updates.md

[ajarbol]

For the record I would like to mention that my default Nginx setup had sw.js, loaded from disk. I needed to add the following directive to my nginx.conf file to ensure a correct lifecycle:

location /sw.js {
    add_header Cache-Control "no-cache";
    expires off;
    access_log off;
}

The defaults might be different in an Express or Apache setup, but maybe this could be considered an addition to https://github.com/mxstbr/react-boilerplate/blob/master/app/.nginx.conf @mxstbr
Many thanks for the above clarifications, they were quite enlightening!

[NekR]

Yeah, SW file should be served without cache enabled for it. Otherwise you may get stale SW up to 24h. Though, that's gonna change per spec SW file will always (unless opt-in) without taking cache into account. But that's future :-)

[gihrig]

I opened PR #1381 to address server cache settings. If others could take a look that would be helpful.

[akarve]

To add my experience, I still consider "obstinate service worker" a problem. We are going to be removing service worker from our production code. Even after implementing the above-recommended onUpdate hooks, we find that SW is immune in many cases to all but hard reload (e.g. Shift+Reload on Chrome). It seems that SW refuses to budge if there are any active tabs that hold the site even in the tab history. We have seen multiple cases of SW refusing to update-in-place even after restarting the browser. This won't work for our production website as we can't afford to show stale content to our users--and it happens often with SW.

Programmatic uninstall not really viable given that SW will block new JS from executing.

[NekR]

Never seen that issue, but thanks for the update.

[SamMatthewsIsACommonName]

I also have this issue with a website that was initially made using this boilerplate, and has since moved to a next.js app as we needed server side rendering. Trouble is even months later I'm still getting an old version of the site from the service worker, and I need to hard refresh to get the actual version. This makes analysing the live site basically imposssible. Is there a way to get rid of this? If I re install chrome would that change anything? Cheers

EDIT: my bad, in my case I can just remove it from the 'application' tab of developer console, but if we had have had customers at that time might have been a problem hehe

[NekR]

Well, a previous person by some reason said that "programmatic uninstall" isn't viable by some mysterious reason. That isn't true of course. Just unregister ServiceWorker from your script and unregistration is done reload the page.

[akarve]

@NekR Are you are referring to this method of unregistering the service worker that I linked above? The problem with said method is, if an existing registered service worker is running, any new code remains in the waiting state and doesn't get a chance to call unregister (exceptions are Shift+Reload, whose effects often revert on reload, and browser restart, which is also unreliable). Service Worker on the latest Chrome even caches index.html. Where do you propose that we insert the unregister() call given that Service Worker will front run almost every resource request? We have seen users pull up months old web content due to this issue.

I have also tried the methods outlined above to no avail.

[michelalbers]

Same here ... it's just impossible to do timed rollouts of features. Customers complaining about stuff not being visible. How can I reliably get rid of service workers?

EDIT

I ended up by removing the OfflinePlugin and serving a noop sw.js:

sw.js

    // A simple, no-op service worker that takes immediate control.
    
    self.addEventListener('install', () => {
      // Skip over the "waiting" lifecycle state, to ensure that our
      // new service worker is activated immediately, even if there's
      // another tab open controlled by our older service worker code.
      self.skipWaiting();
    });
    
    /*
    self.addEventListener('activate', () => {
      // Optional: Get a list of all the current open windows/tabs under
      // our service worker's control, and force them to reload.
      // This can "unbreak" any open windows/tabs as soon as the new
      // service worker activates, rather than users having to manually reload.
      self.clients.matchAll({type: 'window'}).then(windowClients => {
        windowClients.forEach(windowClient => {
          windowClient.navigate(windowClient.url);
        });
      });
    });
    */

I put that file into a directory called static and added it to the build by adding WebpackCopy to my webpack.babel.js:

webpack.base.babel.js

    ...
    new CopyWebpackPlugin([{
        from: 'static',
    }]),
    ...

I then added the following code to app.js:

app.js

    if (navigator.serviceWorker) {
      navigator.serviceWorker.getRegistrations().then((registrations) => {
        for (const registration of registrations) {
            registration.unregister();
        }
      });
    }

I hope that someday all customers will have the new dummy sw.js and I can finally roll out timed deployments. I think Offline capabilities are a nice idea but not practical for most apps. Maybe we should update the docs here to avoid confusing people.

[NekR]

@akarve just update your ServiceWorker code if it's old. Delete caches if you don't want them. Update them if you still need them. You can even put ServiceWorker unregistration code into ServiceWorker if you think that would be better for you.

[dimaryaz]

@michelalbers: I tried your suggestion; very useful! The "navigate" call didn't seem to reload the existing pages, though - I suspect it got intercepted by the old service worker.

I added a "claim" call, and that seems to work for me. Here's my sw.js:

self.addEventListener('install', () => {
  self.skipWaiting();
});
self.addEventListener('activate', () => {
  self.clients.claim().then(() => {
    self.clients.matchAll({ type: 'window' }).then((windowClients) => {
      windowClients.forEach((windowClient) => {
        windowClient.navigate(windowClient.url);
      });
    });
  });
});

[michelalbers]

@dimaryaz nice! Guess this is settled then ;)

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.