workbox is not clearing the cache

[GlauberF]

I do not know what I'm doing wrong.
but when I generate a new build a new service worker does not clear the cache in the browser, it does not update to the latest one.

Example, if I close the browser and open again, it still continues the outdated data, I need to be running multiple times (ctrl + f5) to update the cache.

But I need to see where I'm going wrong, because the end user will not be running multiple times (ctrl + f5)

all this is generating a lot of headache, because we have gone new functionality, but the customer complains that he is not yet showing up the functionality.

my sw configuration file

registering the service worker in my index.html

[mzealey]

I have similar problem - the hash is updating and the worker is reloading correctly when it gets the new one, however the old file is still being served from the cache. Sometimes. This happens on safari mobile, chrome on linux, safari on ios... I have no clue how to go about debugging this unfortunately. I have server-side caching set for JS files but presumably given a hash update in __precacheManifest it should fetch with no http-level caching.

[chetanraj]

I have the same problem, not sure on how to fix.

[jeffposnick]

Hey all—apologies that you're running into these issues, and thanks for your patience.

There are some tips for enabling additional debug information at https://developers.google.com/web/tools/workbox/guides/troubleshoot-and-debug#debugging_workbox

It would be very helpful if you could opt-in to that extra logging info and then take a look at the DevTools console during a situation in which you don't believe the correct updates are taking place. Do you see anything out of the ordinary logged in those scenarios?

[chetanraj]

@jeffposnick - thanks for the reply, if i want enable the debug flag in workbox-build using gulp, how to do that, the one specified is not working for me.

[billyjacoby]

I am having this exact same issue, is there anything I can provide to help get it resolved?

[GlauberF]

@jeffposnick I made several tests, the hash changes but the cache is still the same.
To force and clear the cache, I have to press (ctrl + f5), hence the new updates and cache appear.

How can I force this update and cleanup of all old caches without requiring the user to press (ctrl + f5)?

[jeffposnick]

Apologies that this remains an issue for you. Here are a few more things to try:

• Take a look at the Cache Storage viewer in the Application tab of Chrome DevTools. Do you see any entries listed under the -temp cache?

• What's the code that's included in that extra file you have listed in importScripts? Does it contain any logic that might interfere with serving precached responses?

• We did rewrite some of the precaching logic in the upcoming Workbox v4 release. Updating to Workbox v4.0.0-beta.2, via npm install workbox-cli@beta (or workbox-webpack-plugin@beta) will put you on the new codebase, and I am curious whether you're seeing issues there as well.

[GlauberF]

1 °:

2°:
https://gist.github.com/GlauberF/8524b1bb06d98793de0f7a0ef764561c

I'll try the third if you tell me the other two steps are correct.

[jeffposnick]

Re: #1, when you click on the -temp entry, does anything show up in the cache viewer?

We're very close to a 4.0.0 final release, and it does have a rewritten workbox-precache module, so I think at this point it's worth trying that. (Just to test things out, if nothing else.)

[GarrettGeorge]

I'm having a similar issue and I don't see anything in the -temp entry, whereas the precache entry right below it contains all the files. I have precaching set up, but whenever the build output changes on the server the client is not seeing changes.

[jeffposnick]

@GarrettGeorge if you're using Workbox v4, then there should be only one cache for precached entries now. (We no longer use a -temp cache.)

What gets logged when you update and redeploy on your server, and then reload a client page that has an older version of the service worker active? You should see new entries for the updated precached URLs, and there should be a service worker in the waiting state shown in the Applications panel of Chrome's DevTools.

That updated service worker won't go into effect until it leaves waiting and becomes active, and a recipe like this can be used to control when that happens. (It will also happen automatically when you close all tabs that are open to the current origin, and then navigate back.)

[GlauberF]

Hi @jeffposnick ,

The v4 version was very good.

I have only two questions;

1 - I'm using CLI Workbox, ie I do not use import, so how can I know if it's active and can I reload it, just like it does here: https://developers.google.com/web/tools/workbox/guides/advanced-recipes#offer_a_page_reload_for_users

2 - in Workboxx ClI, can I pass some parameter, to tell which version of the workbox to use, example V3 or V4?

[jeffposnick]

Hello @GlauberF:

1. If you're using the GenerateSW mode in v4, the recipe should pretty much "just work". (That recipe runs in the context of the window, independent of how you're generating your service worker.) If you have skipWaiting: false (the default), then the new service worker template used in v4 will automatically include a message event listener that will call skipWaiting() for you in response to wb.messageSW({type: 'SKIP_WAITING'}):

   workbox/packages/workbox-build/src/templates/sw-template.js

   Lines 38 to 46 in 8379c51

   	<% if (skipWaiting) { %>
   	workbox.core.skipWaiting();
   	<% } else { %>
   	self.addEventListener('message', (event) => {
   	if (event.data && event.data.type === 'SKIP_WAITING') {
   	self.skipWaiting();
   	}
   	});
   	<% } %>

2. You can't toggle between the two versions of Workbox when using the CLI. Your best bet might be to install a specific version of the CLI in a project-specific local node_modules and call the appropriate version directly from there, and not install it globally.