Workbox strategies uncaught no-response

[riso348]

Version

v3.0.0-beta.14

Reproduction link

https://jsfiddle.net/

Steps to reproduce

workbox-strategies.prod.js:1
Uncaught (in promise) no-response: no-response :: [{"url":"https://XXXX/admin/advertisements/create"}]
at a.makeRequest (https://cdn.jsdelivr.net/npm/workbox-cdn@4.1.1/workbox/workbox-strategies.prod.js:1:2145)

@ workbox-core.prod.js:1makeRequest
@ workbox-strategies.prod.js:1

What is expected ?

Caught error or page load at least

What is actually happening?

The webpage at https://XXXX/admin/advertisements/create might be temporarily down or it may have moved permanently to a new web address.
ERR_FAILED

Additional comments?

I have this error at soma of my subpages while using PWA.
How can i help, or send you something more to prevent this error. When i try to refresh the page, there is a Chrome error ERR_FAILED

_{This bug report is available on Nuxt community (#c126)}

[Syrou]

Got the same thing happening in our code.

[AndrewBogdanovTSS]

Same thing here

[edlgg]

Same here. Is there anything I can do to fix it?

[sts-ryan-holton]

Same problem, currently using 3.0.0-beta.16

[MSkred]

Same problem, currently using 3.0.0-beta.16

[pi0]

This is not probably a bug related to PWA module but Workbox itself. Please provide a reproduction so at least we have a way to investigate more. same here is not a way to help to resolve, unfortunately.

Please note that if this error happening for making a request to 3rd party domain: https://developers.google.com/web/tools/workbox/guides/handle-third-party-requests

[isaumya]

I am also facing the exact same issue on my project. Honestly, there is no way to reproduce this error. I test my site like crazy all the time. So, often I open my site on a chrome incognito window with the dev tools open and console or network tab opened and then I load my site. In this scenario, many times it loads without that error and some time in the console I have that error which is being thrown by sw.js. I mean if I go to the Application tab in the dev tools, select Service Worker from the left, I can see 1 red cross beside sw.js when I click on that it takes me to the console and show me that error.

The crazy thing is if I do a soft or hard refresh of that page, that error is no longer there and I have no idea when it will come back again. If you want I can share my site URL if that what you need.

[andrew-boyd]

We're seeing this issue too. A lighthouse audit of our site seems to trigger the error reliably. Lighthouse logs an error under "Best Practices" saying that errors were logged to the console.

url: …workbox/workbox-strategies.prod.js (cdn.jsdelivr.net)
description: no-response: no-response :: [{"url":"https://www.wearebraid.com/"}] at a.makeRequest (https://cdn.jsdelivr.net/npm/workbox-cdn@4.3.1/workbox/workbox-strategies.prod.js:1:2145)

Our site is being hosted via now.sh and all content / file requests should be local (no 3rd-part CDN for images currently).

[phartikainen]

Same issue here, shows with Lighthouse audit

[dchernokur]

Error is consistently triggered by LightHouse in chrome devtools.

• Generate new nuxt project as SPA and with PWA module
• Deploy to now.sh with https://github.com/nuxt/now-builder added
• Run lighthouse audit and see the error in "Best Practices" report

It's preventing me from hitting perfect 100's score 😭

[petrovnn]

Same problem

[ghost]

I'm not sure, but placing '@nuxtjs/pwa' at the end (the last index) of "modules" array in nuxt.config.js solved the problem for me.

can someone confirm?

[petrovnn]

@jbty

It does not work for me :(

Even if you comment out the modules or put @nuxtjs/pwa in the first place.

But in the early stages of development, there was no error.

[ghost]

@petrovnn it's strange, since i update this line it's worked for me. (
it seems that nuxt / pwa is not active in dev mode by default see here), you use nuxt/pwa only on production mode (if dev option is false)

here is the list of the other manipulations that I made:

• Uninstall and delete app cache from windows
• Clear all browsing data from chrome
• Delete .nuxt, dist folder and sw.js and run " generate"

my config:
pwa: { workbox: {}, meta: { theme_color: '#000000', lang: 'fr', ogHost: 'https://sdsedsgwewergwg.com/', nativeUI: true }, icon: {}, manifest: { name: 'frfrfrfrfg.fr', lang: 'fr', display: 'standalone' } },

I hope it will help

I take this opportunity to say that it would be magic if there were more examples of using options in the documentation or even a complete tutorial

EDIT : the error reappeared, I do not understand what this is. If I update the page of my pwa the error disappears but it persists during the first load of my pwa :(

[ch99q]

Been getting the same error too when running trough Lighthouse in my browser.

So I trough it maybe was something with the way chrome runs the audit, and when I tried using https://web.dev/measure/

The problem seem to have disappeared.

[AndrewBogdanovTSS]

@ch99q it's caused by the fact that Chrome is cleaning the previous data before new audit so all your new users will get this error. You can test it yourself by clearing cache and hard resetting the page

[ch99q]

@AndrewBogdanovTSS I realized my answer was incorrect the second I pressed 'comment', it was more running away from the problem. You are completely correct and it should be fixed so the users don't experience the issue.

[kevinmarrec]

Easy Reproduction

1) Go on a website using PWA module (https://lichter.io, https://marrec.io)
2) Clear site data (includes service workers)
3) Go on website -> Works
4) Go offline & refresh -> See error in console + unreachable website
5) Go online & refresh -> Works
6) Go offline & refresh -> Works

Note : If you refresh twice while being online, the issue won't show up when going offline, which means the issue is related to Workbox Offline Strategy.

Google Lighthouse Audits has an offline check after an online one, that's why the audit faces this error too.

[qmolab]

I had the same issue, my SW.js file was stock and looked like so:

importScripts('https://cdn.jsdelivr.net/npm/workbox-cdn@4.3.1/workbox/workbox-sw.js')

// --------------------------------------------------
// Configure
// --------------------------------------------------

// Set workbox config
workbox.setConfig({
   "debug": false
})

// Start controlling any existing clients as soon as it activates
workbox.core.clientsClaim()

// Skip over the SW waiting lifecycle stage
workbox.core.skipWaiting()

workbox.precaching.cleanupOutdatedCaches()

// --------------------------------------------------
// Precaches
// --------------------------------------------------

// Precache assets

// --------------------------------------------------
// Runtime Caching
// --------------------------------------------------

// Register route handlers for runtimeCaching
workbox.routing.registerRoute(new RegExp('/_nuxt/'), new workbox.strategies.CacheFirst ({}), 'GET')
workbox.routing.registerRoute(new RegExp('/'), new workbox.strategies.NetworkFirst ({}), 'GET')

I manually added the following to the bottom of the file:

workbox.routing.setCatchHandler(({url, event, params}) => {
   const strategy = new workbox.strategies.NetworkFirst({networkTimeoutSeconds: 10});
   return strategy.handle({
      request: new Request(url),
   });

And it no longer throws an error, at the expense of double downloading the first page a new user gets when first visiting the website / after clearing browser data. If your pages aren't too large, than this may be effective, though it is definitely not satisfactory. It is interesting to note here that the NetworkFirst workbox strategy does not throw errors. The CacheFirst strategy, on the other hand, does throw an error when it cannot find the resource in either cache or the network, which makes me think there is a problem registering the regex routes, though that seems unreasonable. My page speed did not change when using this hack, so it is viable for me for the time being.

[sefrem]

Hey. I had the same error. Following this StackOverflow response, I changed the caching strategy from CacheFirst to StaleWhileRevalidate and now everything works fine. As it appears the problem is that CacheFirst strategy doesn't work with opaque responses.

[AndrewBogdanovTSS]

@sefrem could you provide an example of your nuxt.config.js? I can't find an option where caching strategy can be set

[sefrem]

@AndrewBogdanovTSS
I'm not using nuxt actually. I just change caching strategies i use in my service worker file sw.js.

[ninest]

Are there any fixes? I'm on ^3.0.0-0, and sometimes I get the error sometimes I don't:

The FetchEvent for "https://mywebsite.com/" resulted in a network error response: the promise was rejected.

workbox-strategies.prod.js:1 Uncaught (in promise) no-response: no-response :: [{"url":"https://mywebsite.com/"}]
    at a.makeRequest (https://cdn.jsdelivr.net/npm/workbox-cdn@4.3.1/workbox/workbox-strategies.prod.js:1:2145)

When I do get the error, the PWA doesn't work at all (the service worker seems to have an error), and the website doesn't work offline

When I don't get the error, everything works fine, and the site loads offline around 75% of the time. I'm not able to reproduce this reliably.

[AndrewBogdanovTSS]

Already tried all of that, the only difference is that I use universal mode

[codingstark-dev]

same issue!!

[codingstark-dev]

Same issue with https://shirime.one/fr and @nuxtjs/pwa": "^3.3.2". If I reload the app the error disappears.

My issue fixed by doing this :

//package.json
"@nuxtjs/pwa": "^3.3.0",

//nuxt.config.js
buildModules: [
"@nuxtjs/pwa"
],
pwa: {
workbox: {
clientsClaim: false
}
},

[pi0]

• Official response: Workbox strategies uncaught no-response #176 (comment)
  • Root cause of "uncaught no-response" might be for several reasons
• As a workaround you can disable clientsClaim option using pwa.workbox.clientsClaim: false in nuxt.config
  • It might or might not fix the issue for your project
  • While it can resolve issue, be aware it can introduce issue with ATH page (see The content is not updated for new releases #415)
• PRs/Ideas welcome to fix root cause (via a PR or new Issue)
• For reporting, please use pwa.workbox.dev: true on production to see full stack trace / error
• We are aware of issue and will try to contact workbox team looking for fix/improvement
• Locking issue to avoid misleading responses and limiting to updates for progress

Updates

Tracking down issue with wokbox debugger enabled in production:

 Network request for '/install' threw an error. TypeError: Failed to execute 'fetch' on 'WorkerGlobalScope': 'only-if-cached' can be set only with 'same-origin' mode
    at Object.wrappedFetch [as fetch] (workbox-core.dev.js:1501)
    at async NetworkFirst._getNetworkPromise (workbox-strategies.dev.js:532)
    at async NetworkFirst.handle (workbox-strategies.dev.js:445)

• Possible related bug in chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=823392
• Possibly related: (service-worker.js) 'only-if-cached' can be set only with 'same-origin' mode sveltejs/sapper-template#34
• Spec: https://developer.mozilla.org/en-US/docs/Web/API/Request/cache

[pi0]

Issue should be fixed/mitigated in v3.3.3 (via #417).

After update and removing clientsClaim: false from config, if still seeing uncaught error in console, please share reproduction link or full stack trace from console and avoid "not works for me" or "works for me with disabling clientsClaim option" replies.

[AndrewBogdanovTSS]

@pi0
https://staging.wonder-shop.io/
v3.3.3
clientsClaim: false

[ram-you]

@AndrewBogdanovTSS
Hi, I see your workbox-cdn have a 4.3.1 version, it means that you have to clean your pwa-module package installation and install a fresh one, because the latest v.3.3.3 uses workbox-cdn v5.1.4.
And don't foget to set clientsClaim: true

[AndrewBogdanovTSS]

@ram-you shouldn't clientClaims be true by default?

[ram-you]

Yes I think. But the most important problem that you have to solve in first is the clean installation of the package (v3.3.3).

[AndrewBogdanovTSS]

@ram-you yes, it was an issue with our assets deployment. sw.js was cached incorrectly, after we refreshed a file and excluded it from cache - it's all got to normal! Thanks a lot for your help! 👍

[ErickPetru]

I want to confirm that the update from @nuxtjs/pwa@3.1.2 to @nuxtjs/pwa@3.3.4 really fixed the console error here on Chrome Lighthouse. The app is with clientsClaim: true and ssr: true.

[MSkred]

Hi all, since longtime the solution clientsClaim: false fix my issue. But previous week I updated all dependencies and ... the issue comeback ^^

"@nuxtjs/pwa": "^3.3.5", "nuxt": "^2.15.3",

[pi0]

Hi @MSkred. If you check other network errors, there seems a CORS issue between herve and files subdomains:

(btw please use a new issue for this if still couldn't figure it out. seems unrelated here)

[MSkred]

@pi0 Ok I created a new issue but it's not a CORS issue because when I checkout on master with another packages version all works fine...

[AndrewBogdanovTSS]

@MSkred could you share a link to your new issue?

[fisherspoons]

Can someone help fix the problem, errors appear sometimes. The version I am using
importScripts('https://storage.googleapis.com/workbox-cdn/releases/6.2.0/workbox-sw.js');

[fisherspoons]

and this trouble with strategy for images I think

[TapanDerasari]

Easy Reproduction

1) Go on a website using PWA module (https://lichter.io, https://marrec.io) 2) Clear site data (includes service workers) 3) Go on website -> Works 4) Go offline & refresh -> See error in console + unreachable website 5) Go online & refresh -> Works 6) Go offline & refresh -> Works

Note : If you refresh twice while being online, the issue won't show up when going offline, which means the issue is related to Workbox Offline Strategy.

I tried the solutions menioned above comments but the issue is still appears.

Does anyone found the solution/workaround?

@jeffposnick any idea or Am I misssing something ?

Thanks in advance.

[nishittops]

Easy Reproduction

1) Go on a website using PWA module (https://lichter.io, https://marrec.io) 2) Clear site data (includes service workers) 3) Go on website -> Works 4) Go offline & refresh -> See error in console + unreachable website 5) Go online & refresh -> Works 6) Go offline & refresh -> Works
Note : If you refresh twice while being online, the issue won't show up when going offline, which means the issue is related to Workbox Offline Strategy.

I tried the solutions menioned above comments but the issue is still appears.

Does anyone found the solution/workaround?

@jeffposnick any idea or Am I misssing something ?

Thanks in advance.

I'm also facing the same issue.

@TapanDerasari Did you find the solution for it?

@jeffposnick

[ziadsarour]

👋 from the Workbox project.

This issue was just brought to my attention, and there's honestly a lot going on here. There are many reasons why you might see a logged message about no-response from Workbox—different root causes will all result in that log message. I wanted to break down a few common scenarios that, based on scanning through this thread, folks might be seeing. If you feel like you're bumping into something that isn't covered, and might be due to an issue with Workbox, feel free to report it in the Workbox issue tracker—please include reproduction steps and a live URL!

Anyway, here's an explanation for some of what's been encountered in this thread. (This might be a repetition of some of the earlier explanations.)

• If you're using an extension like uBlock Origin or something similar, then check to see if your failed requests are due to the extension's URL matching rules. The original post in this issue was for a failure to request https://XXXX/admin/advertisements/create, and that /advertisements/ in the URL certainly makes me suspicious that an ad blocker is responsible. If an ad blocker prevents a network request from succeeding, there's not much Workbox could do about it—unless there's already a previously cached response from a time before the ad blocker was installed, or unless you have "fallback" rules set up in Workbox to serve alternative content when a request fails.
• If you're seeing scenarios like what's described in this comment, then as pointed out elsewhere in the thread, it's due to how the service worker lifecycle works, and calling clients.claim() (or the workbox-core wrapper) will result in the service worker taking control of the open tab immediately after it activates. Without clients.claim(), the service worker won't control a tab until the next time you navigate away and return, so going offline immediately and reloading will result in a page load that isn't under control of the service worker.

Thanks to this comment, I have figured out what was causing my file use-cookie-consent to be blocked : the name. I've renamed my file to use-privacy and everything works !