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.