Link to the code that reproduces this issue

https://github.com/pweisensee/nextjs-slug-conflict

To Reproduce

1. Clone the repo and install: npm install
2. Run npm run build — exits 0 with no errors, listing both conflicting routes
3. Run npm start — server crashes immediately before serving any request

Current vs. Expected behavior

Current: next build (with or without --turbo) completes successfully and prints both conflicting routes without any warning or error:

✓ Compiled successfully
├ ƒ /api/items/[item_id]/details
└ ƒ /api/items/[parent_item_id]/purge   ← no error

npm start then crashes immediately:

Error: You cannot use different slug names for the same dynamic path
  ('item_id' !== 'parent_item_id').

Expected: next build should fail with the same error that next start throws, matching the validation already enforced at runtime by getSortedRoutes.

Root cause

validateAppPaths (build-time) normalizes each route by replacing dynamic segment names with a wildcard and checks for duplicate normalized full paths:

/api/items/[item_id]/details        → /api/items/[*]/details
/api/items/[parent_item_id]/purge   → /api/items/[*]/purge

Because the leaf segments (details vs purge) are different, the normalized paths are different — no conflict detected. Build exits 0.

At runtime, getSortedRoutes builds a trie and enforces that every dynamic segment at the same tree depth shares the same name, regardless of what follows. It catches the item_id vs parent_item_id mismatch immediately and throws.

The gap is directly verifiable:

const { validateAppPaths } = require('next/dist/build/validate-app-paths');
const { getSortedRoutes } = require('next/dist/shared/lib/router/utils/sorted-routes');

const routes = [
  '/api/items/[item_id]/details',
  '/api/items/[parent_item_id]/purge',
];

validateAppPaths(routes);  // no error — build passes ✓
getSortedRoutes(routes);   // throws — runtime crashes ✗

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 25.3.0: Wed Jan 28 20:53:15 PST 2026; root:xnu-12377.81.4~5/RELEASE_ARM64_T6000
  Available memory (MB): 32768
  Available CPU cores: 10
Binaries:
  Node: 22.21.1
  npm: 10.9.4
  Yarn: 4.12.0
  pnpm: N/A
Relevant Packages:
  next: 16.1.6
  eslint-config-next: N/A
  react: 19.2.4
  react-dom: 19.2.4
  typescript: 5.9.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Turbopack, Dynamic Routes

Which stage(s) are affected? (Select all that apply)

next build (local), next start (local), Vercel (Deployed)

Additional context

The error is not caught by TypeScript, ESLint, or next build. It is only visible in server startup logs — by which point the deployment is already live and serving no requests.

On Vercel (Fluid compute), every instance crashes before it can serve a single request. The platform spins up replacements that also crash immediately, creating a crash loop. In our case this drove compute memory costs from ~$0.27/day to $13+/day (~48× increase) in under 15 minutes before we identified and fixed the conflict.

Deployed on: Vercel (Fluid compute). Also reproducible locally with next start.

Suggested fix: validateAppPaths should additionally validate that for any group of routes sharing a common path prefix up to a dynamic segment, the dynamic segment name is consistent across all routes in that group. The simplest implementation would be to call getSortedRoutes on the collected app paths as a final validation step, since getSortedRoutes is already the authoritative validator for this constraint.