next.js/test/e2e/app-dir/parallel-routes-and-interception-nested-dynamic-routes/next.config.js at canary

mirror of https://github.com/hanzoai/next.js.git synced 2026-10-30 14:46:38 +00:00

Files

T

Jiwon ChoiandGitHub 8eaf44b036 Fixed rewrite param parsing for interception routes in Vercel deployments (#79204 )

> [!NOTE]
> - Introduced in [PR #67400](https://github.com/vercel/next.js/pull/67400) and released in [v15.0.0-canary.54](https://github.com/vercel/next.js/releases/tag/v15.0.0-canary.54)
> - See failed test in deployment [GitHub Actions Run](https://github.com/vercel/next.js/actions/runs/15083957601/job/42405327124?pr=79204#step:34:92)

### Summary

This PR resolves two issues related to interception routes and rewrite behavior in Vercel deployments:

1. Rewrite params not parsed correctly from the `NEXT_ROUTER_STATE_TREE_HEADER`, resulting in server crashes due to missing dynamic params.
2. Malformed search query from Vercel deployment, where unresolved dynamic params like `:foo_id` were passed instead of actual values like `1`.

These issues caused runtime errors and incorrect component behavior during navigation in deployed environments. This PR ensures consistent param resolution across local and deployed environments.

### Issue 1: Missing Rewrite Params in Vercel

The `NEXT_ROUTER_STATE_TREE_HEADER` header, introduced in PR [#67400](https://github.com/vercel/next.js/pull/67400), wasn't parsed correctly during Vercel deployment. This was fine locally with `next start`, which uses [`getResolveRoutes`](https://github.com/vercel/next.js/blob/42b1c400c977cbe43147c083714e7f6bd38cff80/packages/next/src/shared/lib/router/utils/resolve-rewrites.ts#L14), but broke in Vercel which used [`handleRewrites`](https://github.com/vercel/next.js/blob/42b1c400c977cbe43147c083714e7f6bd38cff80/packages/next/src/server/server-utils.ts#L208).

```
TypeError: Expected "<a_dynamic_route_slug>" to be a string
    at async Object.handler (___next_launcher.cjs:58:5)
    at async Server.r (../../opt/rust/nodejs.js:2:14674)
    at async Server.<anonymous> (../../opt/rust/nodejs.js:16:6262)
```

This occurred because the expected dynamic route params were undefined, causing `path-to-regexp` to throw when trying to compile the destination path.

### Solution

We ported the interception route rewrite logic from PR #67400, allowing consistent resolution of route params from the `NEXT_ROUTER_STATE_TREE_HEADER`.

### Issue 2: Malformed Query from Vercel

Even after correct interception routing, the query string received from Vercel contained unresolved params such as `:foo_id`, resulting in:

```ts
{
  rsc: 'aaaaa',
  nxtPfoo_id: ':foo_id',
  nxtPbar_id: ':bar_id',
  nxtPbaz: '1',
}
```

Instead of the expected:

```ts
{
  rsc: 'aaaaa',
  nxtPfoo_id: '1',
  nxtPbar_id: '1',
  nxtPbaz: '1',
}
```

This happened because the rewrite rule:

```json
{
  "source": "/:baz_id",
  "destination": "/:foo_id/:bar_id/(...)baz/:baz_id",
  ...
}
```

Did not include `:foo_id` or `:bar_id` in the `source`, so they were never correctly mapped by Vercel CLI's [`convertRewrites`](https://github.com/vercel/vercel/blob/53e3609f144d08ad92d42291bcbf483ae592ff1b/packages/routing-utils/src/superstatic.ts#L165).

### Solution

Since we already parse rewrite params from the `NEXT_ROUTER_STATE_TREE_HEADER`, we now inject those resolved values into `parsedUrl.query`. If any query value still starts with `:`, it's treated as unexpected and replaced with the rewrite params accordingly.

2025-05-19 19:09:29 +02:00

7 lines

96 B

JavaScript

Raw Permalink Blame History

 /**
  * @type {import('next').NextConfig}
  */
 const nextConfig = {}
 module.exports = nextConfig

7 lines 96 B JavaScript Raw Permalink Blame History

7 lines

96 B

JavaScript

Raw Permalink Blame History