Is the service worker cache periodically checked in the background?
Reported by
anders.e...@gmail.com,
Nov 1 2016
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.71 Safari/537.36 Steps to reproduce the problem: This is more of a question than a bug report I guess. We've launched a new site using Service Worker and the cache API. We sometimes see an odd behavior where some of the entries are removed from the cache but others aren't. And we don't really understand how that happens because we never remove individual entries in the cache, we only clear it. The entries that gets removed are static files that get new names when we deploy to enable long term caching (JS and CSS files). But entries where the URL is still accessible never seems to get removed. So my question is if there's a periodic update of the cache in the background which removes the entry if it now gets a 404? What is the expected behavior? What went wrong? Our app shell template loads fine from the SW cache. But the app shell template contains links to JS and CSS that have been removed from the SW cache. And since the JS and CSS files have new names on the server the requests fails. We detect this and clear the SW cache if we get a 404 so a reload fixes it. But the site loads up without any JS and CSS and looks quite bad. Did this work before? N/A Does this work in other browsers? N/A Chrome version: 54.0.2840.71 Channel: n/a OS Version: 6.3 Flash Version: Shockwave Flash 23.0 r0
,
Nov 2 2016
What you're describing is not expected behavior. Per the spec https://w3c.github.io/ServiceWorker/#cache-objects "The Cache objects do not get updated unless authors explicitly request them to be. The Cache objects do not expire unless authors delete the entries. The Cache objects do not disappear just because the service worker script is updated. That is, caches are not updated automatically. Updates must be manually managed." So either you're seeing a bug in Chrome or a bug in your code. Are you able to provide any more data? Have you tried in Firefox? Is your site available to inspect?
,
Nov 3 2016
Hi! Thanks for answering. It's quite possible that the bug is on our side, I mostly wanted to know if you were intentionally refreshing the cache, but good to know that it shouldn't happen. It's incredibly hard to reproduce. We see it perhaps once every 10th deploy, and for only one of ~10 developers. And not on the same computers/phones. The site is lyko.se and you're more than welcome to check it out, but I'm not sure it will tell you much as the code is minified and without sourcemaps. And since the error is so hard to reproduce. But I'd be happy to give you access to our Github repo. I've never heard or seen this happen in Firefox. And I've just recently added a special redirect when we get a request to the outdated bundle so the client gets the new bundle. That should give us more info about how often this happens in the wild.
,
Nov 3 2016
Thanks - keep us posted (here) as you learn more.
,
Nov 11 2016
Thank you for providing more feedback. Adding requester "jsbell@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 15 2016
Adding Needs-Feedback label back again as per # 4.
,
Dec 15 2016
No feedback was received in the last 30 days from reporter "anders.ekdahl@gmail.com", so archiving this. Please re-open or file a new bug if this is still an issue. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by hdodda@chromium.org
, Nov 2 2016Labels: TE-NeedsTriageHelp