[nextjs app router] `ClerkProvider` breaks 404 routing about javascript HOT 11 CLOSED

Update: Seems like the vercel team prioritized the issue and a PR was open to address it.

As a workaround, until the fix is out, prefetch in the <Link/> needs to explicitly be set to true or false.

from javascript.

Please note that this does not occur when running in development. You'll need to build and start the server in order to reproduce this.

from javascript.

For the visual learners out there...

from javascript.

I also got an error deploying on vercel Nextjs 14 but everything was perfect during development.

from javascript.

@kaksv yes, this only seems to occur during while running in dev mode. Notably, this is reproducible locally though by building and serving locally.

from javascript.

There's a worse version of this bug that occurs too. It seems that only navigating to the root page breaks, so there's scenarios like:

1. Navigate to "/fake-page" -> 404 non-found.tsx renders
2. Navigate from there to "/real-page" -> /real-page/page.tsx renders
3. Navigate from there to "/" -> No navigate!

This is really bad! In practice, a 404 page being buggy is much more acceptable than a 404 page breaking a completely unrelated page

from javascript.

Any update on this?
This is really quite bad, and makes Clerk a huge risk to introduce on the App Router.

from javascript.

Hello @JacobJaffe :)
Just wanted to let you know that we're actively working on this. I will get back to you with more details soon.

from javascript.

Hey @JacobJaffe turns out this issue can be replicated just by using nextjs. I have created this issue in their repo. (I used the gif from this PR, I could replace it with on of ours if it bothers you.)

For some context, we are making use of headers() inside of ClerkProvider when this is mounted as a server component which causes the issue. While not ideal you can either add "use client" on top of RootLayout or for now create a custom wrapper with "use client" and only re export ClerkProvider from there.

from javascript.

@nikosdouvlis @panteliselef Thank you for the updates and for looking into this! Looking forward to the upstream fix, and thanks for relaying the workaround.

from javascript.

The fix should have landed in [email protected]

from javascript.