V5: `OrganizationProfile` throws error upon logout about javascript

[oferitz]

@panteliselef Thanks a lot for the help. Yeah, sure, I can use the hash workaround for now, but please keep me updated once it's fixed

[LekoArts]

Hi!

Sorry to hear you're running into an issue. To help us best begin debugging the underlying cause, it is incredibly helpful if you're able to create a minimal reproduction. This is a simplified example of the issue that makes it clear and obvious what the issue is and how we can begin to debug it.

If you're up for it, we'd very much appreciate if you could provide a minimal reproduction and we'll be able to take another look.

Thanks for using Clerk!

[panteliselef]

Hey @oferitz thanks for reporting this. For quickly confirming if the issue has been fixed, you could add do this

<ClerkProvider clerkJSVersion="5.2.0-snapshot.vfc5e305" {...} />

[oferitz]

@panteliselef Thanks! It does solve the original issue, but it strangely introduces a new one:

Even though my page is defined with catch-all routes

[panteliselef]

Yeah, this seems to be unrelated, we are already tracking this internally.

Do you mind doing this explicitly ?

<OrganizationProfile
   routing="path"
   path="/organization"
/>

[oferitz]

@panteliselef Sure, do i need to change the folder structure? because doing this with the current catch-all doesn't seem to render anything on the screen.

[panteliselef]

Is /organization a nested route ? I couldn't tell from the screenshot above, but yes the file structure should match the path.

[oferitz]

OK i made the necessary changes and it renders now, but the error is still present upon signout:

Error: Clerk: The "/main/organization" route is not a catch-all route. It is recommended to convert this route to a catch-all route, eg: "/main/organization/[[...rest]]/page.tsx". Alternatively, update the OrganizationProfile component to use hash-based routing by setting the "routing" prop to "hash".

[panteliselef]

Thanks for the information, this will help us better understand why this is happening. Seems like you are still blocked which is very unfortunate. We have prioritized this issue and we are expecting a fix soon.

Maybe for you to get unblocked you could simply use routing="hash" (with no path) for now.

[panteliselef]

@oferitz this got closed automatically, we are still tracking the 2nd issue you reported, but since the original one is fixed I would keep this closed.

Try updating to latest @clerk/nextjs and removing the clerkJSVersion prop.

[oferitz]

@panteliselef Thanks for the update. Is there a way for me to track the 2nd issue?

[nikosdouvlis]

Hello @oferitz , I'm currently on the issue and I will try to share more details once my investigation is over.
I do have a few ideas about potential edge cases that are related to the way we detect if a route is a catch-all route or not. Could you please share your middleware code?

I'm very interested to find out how you're protecting your routes as this might be connected and it will certainly help me debug :)

[oferitz]

@nikosdouvlis Sure.

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

const isMainRoute = createRouteMatcher(['/main(.*)'])

export default clerkMiddleware((auth, request) => {
  if (isMainRoute(request)) {
    auth().protect()
  }
})

export const config = {
  matcher: ['/((?!.+\\.[\\w]+$|_next).*)', '/', '/(api|trpc)(.*)']
}

[nikosdouvlis]

@oferitz Thank you very much, this does confirm my initial findings. The problem you're hitting is caused by the auth().protect() logic in your middleware. Let me give you some context:

All Clerk components can navigate through their own pages using 3 different strategies:

• path routing: the components will modify the path of the URL that comes after the path they are mounted. Example: if you mount your org profile on /main/organization, the component will use /main/organization as its main route but it will use /main/organization/settings to display the settings page. In this case, we need a catch-all route so the /settings part can be handled by the Clerk component. This is the default for Clerk components in Nextjs apps.
• hash routing: this only modifies just the fragment (the part of the URL that comes after #). This does not need a catch-all route because changing the fragment does not need to trigger a NextJS navigation
• in memory routing: mainly used by modals, does not affect the URL at all but its not bookmarkable -refreshing the page will cause the component to lose its state

When you mount a path-based Clerk component, we try to check whether you are using a catch-all route or not. The only way to do this in NextJS right now is to fire a request to a random URL under the path the component is mounted (eg /main/organization/clerk_catchall_route_check_123123) and see whether this returns a 404 or not.

In your case, a race condition after signing out triggers the error as the component incorrectly fires the catch_all_check request I described above, but this fails because auth().protect() will block the route as you are signed out.

We're sorry for the trouble! This would be very hard to debug on your own. I'm working on updating the detection logic so this false-positive cannot happen again

[oferitz]

@nikosdouvlis Thanks for the thorough explanation. I was actually wondering how you do this check, so thanks for sharing this info. I appreciate the effort. Please keep me posted once it's fixed.