404 (not-found.tsx) triggered when logging out

Question

404 (not-found.tsx) triggered when logging out

Closed this issue 2 months ago · 6 comments

tpiros commented 3 months ago

Preliminary Checks

I have reviewed the documentation: https://clerk.com/docs
I have searched for existing issues: https://github.com/clerk/javascript/issues
I have not already reached out to Clerk support via email or Discord (if you have, no need to open an issue here)
This issue is not a question, general help request, or anything other than a bug report directly related to Clerk. Please ask questions in our Discord community: https://clerk.com/discord.

Reproduction

https://github.com/tpiros/clerk-sample.git

Publishable key

pk_test_Y29oZXJlbnQtcG9ueS02OC5jbGVyay5hY2NvdW50cy5kZXYk

Description

In a Next.js project, when on a protected path, after signing out, if not-found.tsx is added at the root level of the project, the 404 page shows up for a moment before the user gets redirected to the the path specified via <ClerkProvider>'s afterSignOutUrl prop.

To test, throttle the network down to Fast 3G at least to see the 404 page show up. Steps to reproduce: Sign in, Navigate to /protected, Sign out.

Environment

System:
    OS: macOS 14.5
    CPU: (8) arm64 Apple M2
    Memory: 81.64 MB / 16.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.15.1 - /usr/local/bin/node
    npm: 10.5.1 - ~/.npm-global/bin/npm
  Browsers:
    Chrome: 127.0.6533.74
    Chrome Canary: 129.0.6629.0
    Safari: 17.5
  npmPackages:
    @clerk/nextjs: ^5.2.8 => 5.2.8 
    @types/node: ^20 => 20.14.13 
    @types/react: ^18 => 18.3.3 
    @types/react-dom: ^18 => 18.3.0 
    daisyui: ^4.12.10 => 4.12.10 
    eslint: ^8 => 8.57.0 
    eslint-config-next: 14.2.5 => 14.2.5 
    next: 14.2.5 => 14.2.5 
    postcss: ^8 => 8.4.40 
    react: ^18 => 18.3.1 
    react-dom: ^18 => 18.3.1 
    tailwindcss: ^3.4.1 => 3.4.7 
    typescript: ^5 => 5.5.4

Answer 1 · 2024-08-05T11:35:34.000Z

same issue

Answer 2 · 2024-08-06T15:48:39.000Z

Extending the middleware.ts does the job for me.

export default clerkMiddleware(
  (auth, request) => {
  if (!auth().userId && !isPublicRoute(request)) {
    return auth().redirectToSignIn();
  }

  // other config here...
}

Answer 3 · 2024-08-07T18:49:47.000Z

I'm hitting something similar that I think is related to this same issue. From what I can tell, when the sign out occurs you get a POST to the route you're currently on before the redirect happens, which I think is kicked off from this server action in the ClerkProvider. Somehow this makes it here which I think is Clerk trying to force a 404.

In our case this is presenting as a 500 instead of a 404 I think because we have a custom domain on our dev environment. We get a Failed to proxy https://ourdomain.com/clerk_1723055237546 Error: connect ECONNREFUSED 127.0.0.1:443. I can reproduce this on the sample repo provided using a reverse proxy like Caddy in front of it. I'm happy to file this part as a separate issue if that's helpful!

Answer 4 · 2024-08-07T19:35:51.000Z

We are seeing this as well.

Answer 5 · 2024-08-29T06:41:51.000Z

This should be fixed by #4001 and was released in https://github.com/clerk/javascript/blob/refs/heads/main/packages/clerk-js/CHANGELOG.md#5170.

Please remove any workaround you might have added and give it a try, you should automatically get the new version (In the network graph the request for clerk.browser.js will be for 5.17.0).

Answer 6 · 2024-10-17T16:54:35.000Z

I'm seeing this again with clerk.browser.js at 5.27.0.