Every page results in 404 but only from cold start. Anyone else?

[jesper-bylund]

I'm having real issues debugging this since it only seems to happen on cold starts. If prod or local has not had visits for "a few hours" ANY path resolves as 404.
However once refreshed all routes will work perfectly again. I have to wait some random amount of time to see the error again. This happens even with rebooting the server locally.

I've added logging to the middleware and everything is routing fine. Just always resolving the first call as 404.

Has anyone seen this? Anyone know how to debug?

[romhenri]

In Next.js, the 404 on cold start could be due to slow route initialization after inactivity. Ensure proper use of getStaticProps or getServerSideProps and check if your server fully initializes before handling requests. If deploying on Vercel or similar, review any related cold start configurations.

[jesper-bylund]

That's super interesting. Is this still true in Nextjs14 with SSR?

[romhenri]

Yes.

[jesper-bylund]

Apparently not a Nextjs error, just obfuscated by Nextjs routing.
What's happening is the locale of the next-international pacakge is not getting set, resulting in a 404. Why this happens seem to be related to some sort of nextjs cold start though.

app/[locale]/page.tsx -> 404, but on refresh 200

[jesper-bylund]

For anyone else struggling with this. It turns out that next-international doesn't handle a default locale. It's supposed to. But in this combo of versions:

"next": "14.2.13",
"next-international": "1.2.4",

you have to manually set a default local in your root layout component.

[jesper-bylund]

Turns out my investigation in next-international was completely wrong. I'm still getting 404's from cold start.

What seems to be happening is that Nextjs is unable to handle routing from cold start. Why this is is unclear. My middleware does contain a supabase call. So maybe there's a cold starting lambda to make this call that is timing out?

[icyJoseph]

Where is this app deployed to? Is it using App Router or Pages Router? If its a timeout at play, does the 404 take "longer" to resolve?

[jesper-bylund]

@icyJoseph This is deployed to Vercel. It's using App router. And yes the 404 takes a few seconds to resolve.

I found a work around that is highly annoying, following this guide from supabase will result in a 404 from cold start: https://supabase.com/docs/guides/auth/server-side/nextjs

But if the landing page resolves without supabase, everything works fine.

This should mean that cold starting Nextjs on Vercel takes so long that verifying auth from supabase causes a timeout. Making the router resolve as a 404. I didn't find a way to debug this, and for obvious reasons testing is difficult.

[matejm]

Anyone got more details on this? We are facing the same issue (also using Supabase and next-international). Not initializing Supabase on landing page doesn't solve the issue, as users can navigate directly to URLs where authentication is required and still get a 404.

[jesper-bylund]

I solved this eventually, but I honestly don't know how. I just moved things around in the middleware until suddenly it started working. What I think may have happened is that the middleware times out while waiting for supabase to respond, and therefore sends a 404. But again, I sadly don't know.

[icyJoseph]

I learned that undici fetch, the one Node.js implemented, has a rather low timeout of 300 seconds, but I guess that's not the issue here

[brechtpallemans]

I had the same issue, it has nothing to do with cold starts! Problem is when the Access Token JWT from Supabase is expired, it calls the setAll method passed to the Supabase server client. This will likely remove your i18n headers because the documentation code replaces the response object with a new response object:

...
setAll(cookiesToSet) {
  cookiesToSet.forEach(({ name, value, options }) => request.cookies.set(name, value))
  supabaseResponse = NextResponse.next({
    request,
  })
  cookiesToSet.forEach(({ name, value, options }) =>
    supabaseResponse.cookies.set(name, value, options)
  )
}, 
...

[jesper-bylund]

@brechtpallemans Very interesting, thank you for sharing this Brecht. Still does not explain the 404 though? In my case the i18n is either in the URL or headers, and the non i18n URL is still valid. So even without the i18n header it should return a page, just in English.