Nuxt pre-generated routes returning 404 despite existing

Support
,
1

Hiya,

I have a Nuxt 3 site (https://mono.domains/) with a large number (2,000+) of pre-defined routes which are all generated statically.

Looking at the build logs, it appears that all the pages are building completely fine (see snippet below):

3:44:29 PM: [info] [nitro] Initializing prerenderer
3:44:29 PM: [info] [nitro] Prerendering 2062 initial routes with crawler
3:44:30 PM: [log] [nitro]   ├─ /extensions (787ms) 
3:44:30 PM: [log] [nitro]   ├─ / (170ms) 
3:44:30 PM: [log] [nitro]   ├─ /200.html (2ms) 
3:44:30 PM: [log] [nitro]   ├─ /404.html (1ms) 
3:44:30 PM: [log] [nitro]   ├─ /extensions/.xn--qxa6a (9ms) 
3:44:30 PM: [log] [nitro]   ├─ /extensions/.xn--e1a4c (5ms) 
3:44:30 PM: [log] [nitro]   ├─ /extensions/.xn--q9jyb4c (5ms) 
3:44:30 PM: [log] [nitro]   ├─ /extensions/.xn--qxam (5ms) 
3:44:30 PM: [log] [nitro]   ├─ /extensions/.xn--fiqs8s (4ms) 
3:44:30 PM: [log] [nitro]   ├─ /extensions/.xn--i1b1b4ch5i.xn--h2brj9c (5ms) 
...

However, when visiting one of these routes in the browser (https://mono.domains/extensions/.autos) after deployment it initally returns a blank page with a 404 status code. Only when the page hydrates on the client side does it actually show the contents.

It should be noted that it does not return the actual 404 page (https://mono.domains/invalidpage), showing that the file actualy exists but the route is not being generated.

I’ve ran some experiments locally and can’t seem to reproduce this behaviour, which is leading me to believe it’s not a Nuxt issue. I’ve also checked smaller Nuxt sites that I have hosted on Netlify and they don’t appear to have this issue, which is leading me to believe it’s due to the large number of routes.

The Netlify ID of the site is glowing-biscochitos-9a1f05.

Would appreciate any help!

Thanks,
Josh

2

This appears to be expected. This is the list of files in your deploy:

/site.webmanifest
/favicon-16x16.png
/favicon-32x32.png
/fonts/fonts.css
/_nuxt/error-500.b63a96f5.css
/_nuxt/error-404.8bdbaeb8.css
/apple-touch-icon.png
/android-chrome-192x192.png
/favicon.ico
/_nuxt/entry.8fe3536f.css
/android-chrome-512x512.png
/fonts/geomanist-regular-webfont.woff2
/fonts/geomanist-book-webfont.woff2
/fonts/geomanist-bold-webfont.woff2
/fonts/geomanist-book-webfont.eot
/fonts/geomanist-regular-webfont.eot
/fonts/geomanist-bold-webfont.eot
/fonts/geomanist-bold-webfont.woff
/fonts/geomanist-book-webfont.woff
/fonts/geomanist-regular-webfont.woff
/fonts/geomanist-book-webfont.ttf
/fonts/geomanist-bold-webfont.ttf
/fonts/geomanist-regular-webfont.ttf
/fonts/geomanist-bold-webfont.svg
/fonts/geomanist-book-webfont.svg
/fonts/geomanist-regular-webfont.svg
/_payload.js
/extensions/_payload.js
/_nuxt/composables.25be4f0a.js
/_nuxt/pageheader.18000dbe.js
/_nuxt/registrarpricing.705a150e.js
/_nuxt/error-component.e343c048.js
/_nuxt/error-500.fe236e0e.js
/200.html
/404.html
/_nuxt/error-404.5d27f6a1.js
/_nuxt/index.6a8a2794.js
/_nuxt/index.73fa4065.js
/_nuxt/nuxt-link.0720cd08.js
/_nuxt/usemonoapi.de02c19c.js
/_nuxt/index.10172a40.js
/index.html
/_nuxt/entry.92ce5fd6.js
/extensions/index.html

Because you have a 404.html, Netlify automatically tries to load that page. However, the JavaScript on that page then loads the contents for the actual URL.

To handle dynamic paths, you’ve 3 options:

  1. Generate /.tld.html or /.tld/index.html for each .tld
  2. OR use SSR
  3. Use Edge Functions to serve a 200 status code
3

The confusing part is that it already does this, so I’m unsure why those files aren’t being deployed. When running npm run generate locally it generates 2,060 folders as described in the deploy log snippet in the OP.

The fact that they’re also showing up in the deployment log leads me to believe they’re being generated when the site is deployed too, just then not actually deployed to the server?

4

hiya are you still experiencing this issue?

5

Hey there!

Yeah this is still an issue.

I’ve currently moved the site over to use a VPS, which generates all the routes as expected without issue. Though I would love to be able to move it back if we can sort this out!

Is there a cap on the number of files that can be uploaded in a directory? After doing some tests with other static site hosting providers that was an issue. Wondering if the same could apply here?

Thanks,
Josh

6

One theory could be because we ignore folders with the . in the start of its name. I only thought it’s for folders in the root of the publish folder, but looking at your situation, we might be excluding all dot-files and folders.

The solution would be to remove the dot from the start of each.

7

Looks like this did the job!

Thanks a ton for all the help!

8

Glad you found your solution!