Pwa-module: 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/[email protected]/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/[email protected]/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/[email protected]/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/[email protected]/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]

It would be great if someone could provide at least a workaround for this issue. Maybe caching strategy could help, but it seems there is no way to change it via module's settings or at least I didn't find anything regarding such option in the documentation

[neiromendez]

Hi all, I would like handle the workbox lifecycle to notify when an update is available, when a user is offline or a installation is available, using vue cli pwa is easy but with nuxt I don't find any about this.. If someone can help I'll appreciate it.

[AndrewBogdanovTSS]

@neiromendez use discord channel, this is not the place for such requests

[kevinmarrec]

Hi everyone, I'm getting you some some updates today :

From my new investigation, there are two different issues which lead to a common error. Both seem distinct though, and I got a fix for one of them.

Error (giving back context)

Issue 1 : Lighthouse Best Practices test failing

You may have encountered the latter console error during the test, which makes you not able to hit 100 score in Best Practices Lighthouse section.

Good news: I found how to fix it., this is due to this line : https://github.com/nuxt-community/pwa-module/blob/dev/lib/workbox/templates/sw.js#L19.

All you need is to set workbox.clientClaim module option to false.

Issue 2 : Offline may not be totally working

You can check my comment made in April : https://github.com/nuxt-community/pwa-module/issues/176#issuecomment-618314637

This is due to something related to offline strategy, for which I don't have a fix yet.
Any help or thoughts about this second issue is more than appreciated :)

[AndrewBogdanovTSS]

@kevinmarrec I tried your suggestion - it made no effect on lighthouse - error is still here, lowering the score https://take.ms/ylVlv

[Kayoshi-dev]

Hello!

I'm facing the same problem, has anyone found a workaround?

[hjujah]

Tried everything and having still the same issue... Any workaround?

[TheForsakenSpirit]

Have the same issue with CacheOnly strategy.
Changing strategy to CacheFirst, run on it and back to CacheOnly helps, but only for couple reloads of service worker.

[AndrewBogdanovTSS]

@TheForsakenSpirit how do you change cache strategy?

[TheForsakenSpirit]

@AndrewBogdanovTSS
registerRoute( ({ url }) => url.origin.includes('s3.amazonaws.com'), new CacheFirst({ // -> CacheOnly and back cacheName: 'image-cache', plugins: [ new CacheableResponsePlugin({ statuses: [200], }), new ExpirationPlugin({ maxEntries: 2000, maxAgeSeconds: 7 * 24 * 60 * 60, }), ], }), 'GET' );

[AndrewBogdanovTSS]

so you directly modify your sw.js file? Shouldn't it be generated by nuxt plugin?

[TheForsakenSpirit]

@AndrewBogdanovTSS Uh, Sorry!!!
I think this is workbox repository.
And, I found my problem. CacheOnly don`t update cache, when entry has expired..

[kevinmarrec]

I'm all good with https://github.com/kevinmarrec/marrec.io/blob/master/config/modules.js#L16

You can try lighthouse on https://marrec.io/ , I don't have the error anymore.

[AndrewBogdanovTSS]

@kevinmarrec could you edit your original message https://github.com/nuxt-community/pwa-module/issues/176#issuecomment-643150781 ? It wasn't working for me since it's clientsClaim but not clientClaims as you originally wrote https://take.ms/hxTuN

[kevinmarrec]

@AndrewBogdanovTSS Oh yeah sorry, edited :)

[AndrewBogdanovTSS]

@kevinmarrec tested it with clientsClaim but still got the same error

[Divlo]

Yep, tested all the things above and I've got still the error.
The issue is opened for more than a year and still no one solved it ?
The team behind pwa-module should do something...

[jeffposnick]

👋 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.

[AndrewBogdanovTSS]

@jeffposnick ok, but why than adding clientsClaim:false makes no difference to the error? I certainly don't use any ad blocker and am running the test in incognito mode

[jeffposnick]

@AndrewBogdanovTSS—As mentioned, there are a lot of distinct questions raised in this thread—when Workbox logs a no-response error message, it just means that it couldn't obtain a response using the strategy that the request was routed to, and that could happen for a lot of very different reasons.

If you could elaborate on exactly what scenario you're talking I could provide more context as to what might be causing it.

[scalingapps]

I tried all the things above. It seems there is still not a clear work around for this?

[LloydTao]

same issue here. pretty standard out-of-the-box installation, and in Chrome incognito mode.

URL | Description
-- | --
…workbox/workbox-strategies.prod.js(cdn.jsdelivr.net) | no-response: no-response :: [{"url":"https://lloyd.cx/"}] at Object.handle (https://cdn.jsdelivr.net/npm/[email protected]/workbox/workbox-strategies.prod.js:1:1883)

feel free to check https://lloyd.cx/ or its repository LloydTao/portfolio-2020.

the site is served out of the build branch.

[michaelpumo]

I was getting this issue too in "@nuxtjs/pwa": "^3.3.2".

Passing clientsClaim: false in the nuxt.config.js works for me:

// ...other options removed for brevity.
buildModules: [
  '@nuxtjs/pwa'
]
pwa: {
  workbox: {
    clientsClaim: false
  }
}

I'm not sure why or how but it works.

[AndrewBogdanovTSS]

@michaelpumo doesn't work for me unfortunately

[michaelpumo]

@michaelpumo doesn't work for me unfortunately

I am using "nuxt": "^2.14.9" and building to full static. Not sure if that makes a difference.

Make sure you're testing in Incognito mode of Chrome to ensure no extensions are interfering. Maybe also try deleting any cache?

[AndrewBogdanovTSS]

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

[refoxdev]

same issue!!

[refoxdev]

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: https://github.com/nuxt-community/pwa-module/issues/176#issuecomment-665722983
  
  
  
  • 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 #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: https://github.com/sveltejs/sapper-template/issues/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/[email protected] to @nuxtjs/[email protected] 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...