Middleware causes router to choose root server-rendered [...catchall] over more specific dynamic route only in production

[Winwardo]

Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

I am using codesandbox with 12.2.4-canary.9, I don't know why next info is reporting 12.1.7-canary.46 - if that were correct, this example wouldn't run at all as I'm using top level middleware.

sandbox@sse-sandbox-kfj5rr:/sandbox$ sandbox@sse-sandbox-kfj5rr:/sandbox$ npx --no-install next infonpx --no-install next info

Operating System:
  Platform: linux
  Arch: x64
  Version: #45~20.04.1-Ubuntu SMP Mon Apr 4 09:38:31 UTC 2022
Binaries:
  Node: 14.19.3
  npm: 6.14.17
  Yarn: 1.22.19
  pnpm: N/A
Relevant packages:
  next: 12.1.7-canary.46
  react: 18.2.0
  react-dom: 18.2.0


Operating System:
  Platform: linux
  Arch: x64
  Version: #45~20.04.1-Ubuntu SMP Mon Apr 4 09:38:31 UTC 2022
Binaries:
  Node: 14.19.3
  npm: 6.14.17
  Yarn: 1.22.19
  pnpm: N/A
Relevant packages:
  next: 12.1.7-canary.46
  react: 18.2.0
  react-dom: 18.2.0

warn - Latest canary version not detected, detected: "12.1.7-canary.46", newest: "12.2.4-canary.9".
Please try the latest canary version (npm install next@canary) to confirm the issue still exists before creating a new issue.
Read more - https://nextjs.org/docs/messages/opening-an-issue
warn - Latest canary version not detected, detected: "12.1.7-canary.46", newest: "12.2.4-canary.9".
Please try the latest canary version (npm install next@canary) to confirm the issue still exists before creating a new issue.
Read more - https://nextjs.org/docs/messages/opening-an-issue

What browser are you using? (if relevant)

How are you deploying your application? (if relevant)

Deployed to Vercel

Describe the Bug

Top level middleware appears to be breaking routing to routes with dynamic segments, in favour of a less specific root [...catchall].tsx that uses getServerSideProps.

1. Given the following directory structure:
   

2. where all pages except [...catchall].tsx are simple components (no use of getServersideProps or getStaticProps) similar to this:
   

3. and a top level middleware that applies only to /broken/:path*
   

4. when trying to access a route broken/[userid]/edit with middleware in front of it, NextJS is routing instead to the less specific [...catchall].tsx, which uses getServerSideProps
   

6. notice how the URL is still pointing at the broken route /broken/somevalue/edit. This happens even if the [...catchall] redirects.

This does not happen if:

• You are running in development.
• You use [catchall] instead of [...catchall] (i.e. you use a dynamic route segment, but not one that is a catch all)
• The catchall does not use getServerSideProps
• There is no catchall route
• The target path does not have middleware applied to it
• You use previous versions of NextJS where you have a colocated _middleware.ts

I have not tried:

• Moving the catchall to another location

Expected Behavior

Adding middleware in front of a dynamic route should not affect routing.

Link to reproduction

https://codesandbox.io/s/nextjs-12-2-middleware-catchall-issue-kfj5rr?file=/pages/index.tsx

To Reproduce

This bug ONLY appears after building. It does not happen when running next dev.

// ✔️ [...catchall]
// ✔️ middleware
// ✔️ bug
// https://csb-kfj5rr-pjwuo58u8-winwardo.vercel.app/

// ✔️ [...catchall], but without getServerSideProps
// ✔️ middleware
// ❌ bug
// https://csb-kfj5rr-dl8707jrw-winwardo.vercel.app/

// ❌ [...catchall]
// ✔️ middleware
// ❌ bug
// https://csb-kfj5rr-l5obh31us-winwardo.vercel.app/

// ❌ [...catchall]
// ✔️ [query]
// ✔️ middleware
// bug
// https://csb-kfj5rr-pnre13we2-winwardo.vercel.app/

[Winwardo]

It feels like #39255 and #39256 are closely related to this issue too

[mmmulani]

also seeing this issue, ping @javivelasco on this ^

[Winwardo]

This appears to be fixed both in my CodeSandbox example, and large personal project, in 12.2.5-canary.0, possibly from this change: a679a1e

@mmmulani Does 12.2.5-canary.0 fix it for you too?

[mmmulani]

hmmm it does solve it for me though that commit makes it seem like the opposite behaviour is desired? will comment on the PR #39370 asking for clarification

[ijjk]

Closing as this should be resolved in the latest version of Next.js

[github-actions]

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.