[Bug - next-pwa]: FetchEvent.respondWith received an error

[aaronabf]

Provide environment information

next - 13.4.19
@ducanh2912/next-pwa - 9.5.0

Link to reproduction - Issues with a link to complete (but minimal) reproduction code help us address them faster

n/a

To reproduce

We are unable to successful reproduce the issue.

Describe the bug

We run this fork of next-pwa and are having users sporadically seeing this error message in Safari:

Safari can't open the page.
The error was: "FetchEvent.respondWith received an error: no-response: no-response :: ["url":"https://our-homepage-here"}]"

My best guess is it's an issue with this code block here, but I do not know this codebase very well.

Expected behavior

For this error to not surface.

Screenshots (if relevant)

No response

Additional information (if relevant)

No response

[DuCanhGH]

packages/next-sw is not what you are currently using as it is a work-in-progress at the moment. It is actually packages/next-pwa. Sounds like a weird issue, will investigate when I'm free :)

[aaronabf]

packages/next-sw is not what you are currently using as it is a work-in-progress at the moment. It is actually packages/next-pwa. Sounds like a weird issue, will investigate when I'm free :)

I see! Thanks for the quick reply.

There is this Stackoverflow post:

My PWA app sometimes cannot get data from server. It shows errors like: FetchEvent.respondWith received an error: no-response: no-response Fetch API cannot load no internet connection But if we reload the page, it could get data normally. And these bugs only happened in Safari. It is working well in Chrome or window devices.

This seems to align with what we are seeing as well, as only Safari users have reported issue and the sporadic nature can be explained by a spotty connection. This might just be a Safari bug but I wonder if there is some way to more gracefully avoid this failure.

[DuCanhGH]

@aaronabf went through the repo and yeah, maybe it's due to a slow internet connection. I honestly don't know why this is happening and how to fix it either. Seems like a Workbox or Safari issue because I've not found anything in the repo that could be causing this :( Maybe some help on reproducing would do the trick.

[pz129]

@DuCanhGH It seems to go away whenever you clear the browser cache. Once someone hits it, they will consistently have the issue until the cache is cleared.

[pz129]

@DuCanhGH any updates as to why this might be happening? it's not a good UX to tell users to clear their cache when this happens. Ideally it goes away without having to clear the cache.

[DuCanhGH]

@pz129 I haven't a clue either. This can't really be reliably reproduced, so there's that.

[DuCanhGH]

@aaronabf can I have your withPWA config and sw.js? I'd like to inspect the service worker to see if there's some weird stuff there. I found this looking at minified workbox:

addFetchListener() {
  self.addEventListener("fetch", (t) => {
    const { request: e } = t,
      s = this.handleRequest({ request: e, event: t });
    s && t.respondWith(s);
  });
}

They made sure that the response is defined before calling event.respondWith, so I'm not sure what can even cause this issue. That's the only mention of respondWith, mind you. So it's most likely an internet connection issue, but I'm not sure why next-pwa is caching a non-response though.

[aaronabf]

Huh that's really odd.

Our configuration is fairly minimal:

const withPWA = require("@ducanh2912/next-pwa").default({
  dest: "public",
  register: true,
  skipWaiting: true
})

And the sw.js can be found here: https://www.passes.com/sw.js

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[DuCanhGH]

Just got this problem on my device today 😂 Took months to actually get it once. I'm guessing that this happens because there's no cached page to serve. Can you try using offline fallbacks to see if that helps?

[FixDev]

Any update for this issue?

[DuCanhGH]

@FixDev this can happen when a Workbox strategy fails to find a response from both the cache and the network. To fix this, try using fallbacks or handlerDidError or precaching the URLs via additionalManifestEntries.

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.