Service-Worker stays in waiting state in Chrome

Question

I'm working on a SPA with Vue. I'd like to update to a new service-worker when the user navigates to a specific page. A save moment to refresh, because the view of the user already changes (a pattern discussed in this video: https://youtu.be/cElAoxhQz6w)

I have an issue that sometimes (infrequently) the service-worker won't activate while calling skipWaiting. The call is made correctly, and even in Chrome I get a response that the current service-worker stops (see animated GIF), however it the same service-worker starts running again, instead of the waiting one.

After a while (1-2 minutes) the service-worker is suddenly activated. Not a situation you want, because it happens just out of the blue when the user might be in the middle of an activity.

Also when I am in this situation I can't activate the service-worker by calling skipWaiting (by doing multiple navigations) again. It's received by the service-worker but nothing happens. It stays in "waiting to activate". When I press skipWaiting in Chrome itself, it works.

I have no clue what goes wrong. Is this an issue with Chrome, workbox or something else?

Most close comes this topic: self.skipWaiting() not working in Service Worker

I use Vue.js, but I don't depend on the pwa plugin for the service-worker. I use the workbox webpack plugin.

I've edited the example code below, the minimal code probably didn't show the problem well

In main.js:

let sw = await navigator.serviceWorker.register("/service-worker.js", {
  updateViaCache: "none",
});
let firstSw = false;

navigator.serviceWorker.addEventListener("controllerchange", () => {
  // no need to refresh when the first sw controls the page, we solve this with clientsClaim
  // this makes sure when multiple-tabs are open all refresh
  if (!firstSw) {
    window.location.reload();
  }
});

sw.onupdatefound = () => {
  const installingWorker = sw.installing;

  installingWorker.onstatechange = async () => {
    console.log("installing worker state-change: " + installingWorker.state);

    if (installingWorker.state === "installed") {
      if (navigator.serviceWorker.controller) {
        firstSw = false;
        // set the waiting service-worker in the store
        // so we can update it and refresh the page on navigation
        await store.dispatch("setWaitingSW", sw.waiting);
      } else {
        console.log("First sw available");
        firstSw = true;
      }
    }
  };
};

In router.js:

// after navigation to specific routes we check for a waiting service-worker.
router.afterEach(async (to) => {
  if (to.name == "specificpage") {
    let waitingSw = store.getters["getWaitingSW"];

    if (waitingSw) {
      waitingSw.postMessage("SKIP_WAITING");
      // clean the store, because we might have changed our data model
      await store.dispatch("cleanLocalForage");
    }
  }
});

In service-worker.js:

self.addEventListener("message", event => {
  if (event.data === "SKIP_WAITING") {
    console.log("sw received skip waiting");
    self.skipWaiting();
  }
});

user_123395 · Answer

skipWaiting() isn't instant. If there are active fetches going through the current service worker, it won't break those. If you're seeing skipWaiting() taking a long time, I'd guess you have some long-running HTTP connections holding the old service worker in place.

user_385997 · Answer

I'm not sure that

let sw = await navigator.serviceWorker.register("/service-worker.js", {updateViaCache: "none"});

if (sw.waiting) {
  sw.waiting.postMessage("SKIP_WAITING");
}

is the code that you want in this case. Your if (sw.waiting) check is only evaluated once, and the newly registered service worker might still be in the installing state when it's evaluated. If that's the case, then sw.waiting will be false-y at the time of initial evaluation, though it may be true-thy after a small period of time.

Instead, I'd recommend following a pattern like what's demonstrated in this recipe, where you explicitly listen for a service worker to enter waiting on the registration. That example uses the workbox-window library to paper over some of the details.

If you don't want to use workbox-window, you should follow this guidance check to see if sw.installing is set after registration; if it is, listen to the statechange event on sw.installing to detect when it's 'installed'. Once that happens, sw.waiting should be set to the newly installed service worker, and at that point, you could postMessage() to it.

user_1213795 · Answer

Ok i had a similar issue and it took me two days to find the cause.

There is a scenario where you can cause a race condition between the new service worker and the old if you request a precached asset at the exact same time you call skip waiting.

For me i was prompting the user to update to a new version and upon their confirmation i was showing a loading spinner which was a Vue SFC dynamic import which kicked off a network request to the old service worker to fetch the precached js file which basically caused both to hang and get very confused.

You can check if your having a similar issue by looking at the service worker specific network requests (Network requests button in the image below) that are happening and make sure they aren't happening the instant you're trying to skip waiting on your newer service worker.

Service-Worker stays in waiting state in Chrome

3 Answers