Service worker stuck in busy state with NetworkFirst requests

[joshkel]

Library Affected:

workbox-strategies 6.0.2

Browser & Platform:

Tested on Google Chrome 87.0.4280.141 for Windows

Issue or Feature Request Description:

My application is set up with the "offer a page reload" recipe and has a route registered with NetworkFirst. However, I noticed that the application wasn't responding when I clicked the upgrade prompt. Going under DevTools -> Application -> Service Workers and clicking "skipWaiting" next to the new service worker instance also seemed to have no effect. If I clicked "stop" next to the old service worker instance to forcibly terminate it, the application reloaded as expected. If I waited 5 minutes, the application reloaded as expected.

As best as I can tell, the symptoms are identical to #2692, except that I'm not using server-side events.

If I replace my NetworkFirst strategy with StaleWhileRevalidate, everything works.

Similar to #2692, calling waitUntil seems to fix this. Specifically, I found NetworkFirst's Promise.race call at

workbox/packages/workbox-strategies/src/NetworkFirst.ts

Line 120 in 025657c

let response = await Promise.race(promises);

and inserted a waitUntil call there:

        let responsePromise = Promise.race(promises);
        handler.waitUntil(responsePromise);
        let response = await responsePromise;

I'm happy to open a PR if that would help, although, after reading the discussion at #2692, I wasn't sure if that's the correct fix.

[jeffposnick]

Thanks for reporting this.

I would like to get to the bottom of this behavior—if we need to make changes to add in extra waitUntil() calls, then that's doable, but not understanding why means that we're potentially just papering over a larger issue.

Could you share the URL for your web app? You could DM @jeffposnick on Twitter if you can't share it publicly on GitHub.

[jeffposnick]

After debugging further, there is an active WebSocket connection established by the web app, so this is a duplicate of #2692

[joshkel]

Thanks for investigating, @jeffposnick; I really appreciate it. I've been able to reproduce the issue without the WebSockect connections, so I don't think it's a duplicate. I sent you a DM with more details.

[jeffposnick]

(This is a different issue, due to the NetworkFirst strategy waiting on a timeout promise that never resolves.)

[jeffposnick]

This is fixed in the v6.1.1 release.