workbox: index.html cached in a bad state when service worker updates after a deployement
Library Affected: workbox-webpack@3.1.0
Browser & Platform: Google Chrome v67
Issue or Feature Request Description: Hi, we are using workbox in our company to power our PWAs. We noticed a bug that is hard to reproduce and it is affecting some of our clients sporadically. They have to clear their cache in order to get the app working again. I stumbled upon the bug yesterday myself when reloading after a deployment, here’s the steps :
- we deployed a new version of the app (we are using webpack plugin, so a new precacheManifest as been generated at build time)
- we reload the page in production to get the update
- a new service worker is installing, after finishing we automatically reload the page using
window.location.reload()as a callback of thestatechangeevent (and checkingevent.target.state === 'installed') - After reloading the page is broken it won’t load assets.
What happened ? The new service worker is active and up to date, the precache manifest as well, I can see old revisioned assets are successfully deleted from the cache using Chrome devtool but when I look at the content of the cached index.html is the one from the previous version. It is referencing for assets matching the previous version revision, it can’t fetch them because they are deleted from the cache by this time.
I don’t know if this is a bug of workbox not updating the index.html in cache despite the new revision number, or somehow a timing issue with our server, serving the new service worker before busting some internal cache for the index.html (it is served with max-age=0 headers).
If anyone can bring some lights with this, it could be very helpful to solve this problem. Unfortunately, I can’t provide any repro since it is very hard to reproduce, but if someone can give clues or workaround, it may help me to understand the issue better. Is there any recommended practices for dealing with this particular problem.
Thank you.
ps: here a screenshot I took, on the left it is an incognito window showing the right index.html being cached. On the right, the original window showing the obsolete index.html in cache.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 14
- Comments: 20 (1 by maintainers)
i have same issues
@AlexandreBonaventure ,
Same problem here - Deploying a new version is a nightmare for the support’s team… 😃 Did you find a workaround or solution ?
@sebastienroul actually yes ! In fact, I was mostly using service-workers with PWA, thus making sure to configure server configuration as you can read here: https://github.com/vuejs-templates/pwa/blob/development/docs/prevent_caching.md#how-to-add-caching-headers-for-your-server
We are running a nginx server so I basically copy paste the snippet. However, this was not suiting our case because this snippet make any 404 fallback to index. This can be catastrophic, let’s imagine your server fails to serve main.css loaded by your app, instead of returning a real 404 (remember if any file return with a 404, the service worker installation will just stop), the server will instead serve index.html. Your service worker is like: hum great we have a 200 let’s store it locally. Next time the user refresh, your service worker is taking control, serving the css with html content. Consequence: syntax error!
In order to fix we had to tweak the config to disable the fallback for actual files (aka the dot rule) https://stackoverflow.com/questions/13812550/configuring-nginx-for-single-page-website-with-html5-push-state-urls/32137788#32137788
If you are using express I suggest you take a look at https://github.com/bripkens/connect-history-api-fallback#disabledotrule
We don’t have any problem anymore since we tweak our server config
@Tirumaleshwar and all, as I mentioned 6 month ago, we had the same problem… I can assure we experiment many solutions, but none was perfect - and clients complained again and again… So I decided to fix definitively the problem with a stupid “brute force” solution, and since 3 month, we have NO problem. The solution is very simple : the missing resource, usualy a JS file, normaly do something (create a global variable, modify the DOM or whatever) : in our case, the JS file add a div with an ID “#q-app” : Anyway : WHATYOUWANT created.
In the index.html I had a stupid interval loop for checking if the #q-app was there or not, and, if after 15sec it’s not there, then :
I know it’s not very elegant, but since 3 month NO MORE call from client about the “blank page”
Hope this workaround will helps as many people as possible, cause after so many nights spent to upgrade everything I was tired 😃
I’ve run into the same issue. I’ve tried several different ways to fix this, but neither of them seems to work. The workaround from @sebastienroul seems to be the best solution so far for our project, but there definitely should be better solution.
I would appreciate any help with this.
@AlexandreBonaventure ,
How did this fix the issue of a stale index.html that you mentioned in your first post?