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

[tpiros]

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

[Sasha95]

same issue

[MarLapuz]

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...
}

[npbee]

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!

[MisterJimson]

We are seeing this as well.

[LekoArts]

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).

[MisterJimson]

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

[victor9000]

This error is still being discussed in discord:
https://discord.com/channels/856971667393609759/1332653566921281577/1332653566921281577

And I'm encountering the bug on the most recent releases, so it's still an active bug:
@clerk/elements@0.22.23
@clerk/nextjs@6.12.0

Here's the workaround I'm using, but this simply avoids triggering the bug:

import { clerkMiddleware, createRouteMatcher } from '@clerk/nextjs/server';

// public
const isPublicRoute = createRouteMatcher([
  '/',
  '/sign-in(.*)',
  '/sign-up(.*)',
  '/api/webhook(.*)',
]);

// check everything that is not public
export default clerkMiddleware(async (auth, req) => {
  if (!isPublicRoute(req)) {
    const { userId, sessionId, redirectToSignIn } = await auth();
    if (!userId || !sessionId) {
      redirectToSignIn();
    }
    auth.protect();
  }
});

// skip next.js internals and all static files, unless found in search params
export const config = {
  matcher: [
    '/((?!_next|[^?]*\\.(?:html?|css|js(?!on)|jpe?g|webp|png|gif|svg|ttf|woff2?|ico|csv|docx?|xlsx?|zip|webmanifest)).*)',
  ],
};

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.