Extremely weird routing bug(s)

[bogdanciuca]

It seems that in various scenarios, the app inconsistently redirects to /.

I first encountered this behaviour when trying to directly access a non-existing route (i.e. https://vitesse-nuxt3.netlify.app/non-existing-route) and then hit refresh. Sometimes it happens after the first refresh, but usually after at most four refreshes, the redirect occurs.

This also happens consistently when using NuxtLink with href="/some-route" and target="_blank". Instead of loading the catch all route, the app redirects to /.

After further testing, it seems to happen on existing routes too (i.e. https://vitesse-nuxt3.netlify.app/hi/antfu). Same behaviour, after 1-4 refreshes, it redirects to /.

Furthermore, when using SSG and linking static files (i.e. PDFs in my case), they never load when clicking the NuxtLink, but redirect to /. They can be accessed directly, but after loading the app, this stops working too.

My current workaround is to disable pwa alltogether, so any suggestions are appreciated!

[userquin]

check antfu/vitesse-nuxt#98 and #66

EDIT: some explanations here with SvelteKit (same problem with same solution): vite-pwa/sveltekit#65 (comment)

[bogdanciuca]

@userquin thanks for the quick response! I assume this also impacts SSG (I am not using SSR at the moment)?

I will try the solution you mentioned in vite-pwa/sveltekit. Would this be a workaround until #66 is fully implemented and merged?

[userquin]

@bogdanciuca yes, it is about dynamic pages: should be excluded with denylist and runtime caching entry, the current PR is too complex to be solved programatically, ppl can have distinct caching strategies and options (per route, per routes group...). My suggestion, include custom runtime caching for those routes.

NOTE bout the draft PR: I need to do some research, but it won't be merged anytime soon (or maybe ever)

[bogdanciuca]

@userquin I see, thanks for the additional context!

Should I then also exclude static files with denylist / runtime caching entry? What about the catch all route?

[userquin]

@bogdanciuca since you're using nuxt generate (SSG), any static page can be included in the sw precaching will work properly on page refresh, don't add them to the denylist.

About the catch all route, I suggest you to use custom Nuxt error page or use the default provided by Nuxt, you can check an example in the elk.zone repo. You don't need to do anything special for it.

[bogdanciuca]

@userquin all my pages, including "dynamic" ones are currently generated. Although I've seen the issue in vitesse-nuxt3, I don't have it, probably because I'm using crawlLinks: true.

By static files I mean assets (i.e. PDF files). They don't seem to load in the browser, as mentioned above. Maybe this is a different issue?

Furthermore, when using SSG and linking static files (i.e. PDFs in my case), they never load when clicking the NuxtLink, but redirect to /. They can be accessed directly, but after loading the app, this stops working too.

Regarding the catch all route, I'm using this.

[userquin]

@userquin all my pages, including "dynamic" ones are currently generated. Although I've seen the issue in vitesse-nuxt3, I don't have it, probably because I'm using crawlLinks: true.

do you have an html page per dynamic route in the output build? If so, check my PR in vitesse-nuxt repo, instead the default page you should redirect to the prerendered route in the runtime caching

By static files I mean assets (i.e. PDF files). They don't seem to load in the browser, as mentioned above. Maybe this is a different issue?

Are the pdf files in the public folder? If so you can add the pdf extension to workbox.globPattern (precaching, will work also when offline) or add a custom runtime caching for them (same origin and the pathname ends with .pdf, will work offline after second pdf download)

Regarding the catch all route, I'm using this.

You don't need to do anything

[bogdanciuca]

do you have an html page per dynamic route in the output build?

Yes, I do. Will check your PR, although I haven't encountered any issues with them so far.

Are the pdf files in the public folder?

Yes, of course, a subfolder of public. I will try to add the PDF extension, although the issue occurs when online (haven't tested it offline).

You don't need to do anything

Hmm, nuxt-vitesse is using the same and it still has the issue.

[userquin]

About pdf files, if you dont add them to the sw precaching (globPattern) you need to add .pdf files to the denylist (/\.pdf$/), otherwise you will get home page response

[userquin]

Check the service worker in the elk.zone repo (service-worker/sw.ts), check the denylist entries

[bogdanciuca]

I'll give it a try and get back with an update. Thanks again for all your help!

[userquin]

You dont need to include a custom sw , generateSW will generate similar code in elk, any resource not in the sw precache manifest should be excluded from sw nav controller (denylist) and optionallly included in a custom runtime caching if required

[bogdanciuca]

@userquin got a chance to test your suggestions and they worked, thanks again!

[bogdanciuca]

@userquin sorry to bother you again, but it seems I can still reproduce the PDF issue. I recently replaced the old PDF with a much larger one (~48MB). Any idea why this would happen? Are there any size constraints?

Update: I managed to get the file size down to 3.5MB via compression. It still redirects to /, not matter if I'm online or offline. 😢

[userquin]

@bogdanciuca if the PDF is added to the sw precache manifest then check this https://vite-pwa-org.netlify.app/guide/faq.html#missing-assets-from-sw-precache-manifest

EDIT: you should have a warning in the console when building... workbox just shows a warning, should be an error

[bogdanciuca]

@userquin I was wondering why my other files were working, being under 2MB. Thank you! 🙇

PS: That piece of documentation might be better placed somewhere else, a place a bit more visible than FAQ, if I may suggest.

[userquin]

@bogdanciuca because workbox build shows the warning and remove the entry from sw precache manifest, then requesting the pdf will be intercepted by the sw and the controller will use the fallback.

IIRC in previous comments I mention 2 solutions for the PDF:

• include it in the sw precache (since workbox removing it from the sw precache...)
• include the .pdf extension in the deny list (avoid controller to use the fallback) and (optional) include the .pdf extension in a custom cache

[userquin]

PS: That piece of documentation might be better placed somewhere else, a place a bit more visible than FAQ, if I may suggest.

any suggestion are welcome (and PR ;) )

[bogdanciuca]

@bogdanciuca because workbox build shows the warning and remove the entry from sw precache manifest, then requesting the pdf will be intercepted by the sw and the controller will use the fallback.

The thing is that I wasn't getting any warning...

IIRC in previous comments I mention 2 solutions for the PDF:

Yes, I went with adding the extension to workbox.globPatterns.

any suggestion are welcome (and PR ;) )

Will do!