Affected version
Reports that share this version, grouped in one feed.
When a compile pipeline change (e.g. turbopack.rules loader, reactCompiler) invalidates most of the module graph, `next build` over an existing `.next/cache` is significantly slower and uses more memory than a cold build, often causing OOM on constrained CI. The persistent cache retains stale entries during rebuild and lacks mass-invalidation fallback.
Setting `"type": "commonjs"` in a Next.js project using Turbopack causes build and dev failures because Turbopack enforces the declared module format on App Router source files (which are written as ESM) and on generated `.next-internal` server-action entries, even though Webpack ignores this field. The issue affects all App Router files and internal virtual modules, not just the `'use client'` proxy previously fixed.
When a deploymentId is configured, Server Action responses do not include the x-nextjs-deployment-id header, so stale clients cannot detect version skew and attempt to apply incompatible flight data, causing a Turbopack runtime crash.
With partialPrefetching enabled, dynamic pages are rendered four times per request (request, runtime prefetch, shell upgrade x2). Timers scheduled during each render capture AsyncLocalStorage context and retain large React Flight request and cache state, causing memory retention of ~3.8 MiB per request for a 10-minute timer, up to 45 GiB at 20 rps.
Next.js 16.3.x uses httpxy for rewrites with a shared keep-alive agent, which can reuse an idle socket at the same moment the upstream closes it, causing a race condition that intermittently returns 500 on the second socket connection.
在 next dev 使用 Turbopack 时，编辑经过 turbopack.rules 配置的 loader 处理的文件会触发 loader 链执行两次。第一次调用传入文件旧内容，第二次传入新内容。对于依赖文件 mtime 或自行读取文件系统的 loader（如 @tailwindcss/turbopack），可能导致缓存陈旧，最终输出滞后一个编辑版本。Webpack 模式无此问题。
When a route with dynamicParams:false calls notFound(), it returns 200 with not-found UI if a root loading.tsx and a sibling dynamicParams:true route exist. The 404 status is lost during streaming; the incremental cache stores a 200 response.
In Next.js App Router, when a `useServerInsertedHTML` callback returns an empty Fragment (or null, empty array), the server still performs an additional React render for each streamed chunk because the callback result is always wrapped in a keyed Fragment, preventing the existing empty-result optimization in `getServerInsertedHTML()`. This leads to significant performance overhead in streaming scenarios with many Suspense boundaries.
In Next.js Pages Router, calling res.revalidate('/') after a content publish can return success while the next request still serves the pre-publish version. This occurs when a normal background ISR render is already in-flight and reads data before publication; the on-demand revalidation reuses that in-flight render, and the stale result is persisted with a fresh cache timestamp.
Next.js 16.3 introduced a regression where route handler modules are not eagerly evaluated at startup, causing the first request to a route handler to pay full module evaluation cost. This increases cold start latency and p99 for deployments.
In mixed App Router and Pages Router applications, Pages Router links to App Router routes trigger erroneous `_next/data` prefetch requests that return 404, and App Router links to Pages Router routes send RSC prefetch requests that receive HTML documents instead of Flight data.
Next.js cacheComponents span-creation exemption is applied after instrumentation.register() returns, but @vercel/otel FetchInstrumentation captures a concrete Tracer during register(); subsequent outgoing HTTP requests in prerender create spans through that unpatched tracer and trip the sync-IO guard, producing a Math.random() prerender error.
When reactCompiler and turbopackRustReactCompiler are enabled, the Rust React Compiler runs in the preprocess stage before user-registered swcPlugins, so macro plugins like @lingui/swc-plugin see compiler-hoisted JSX and emit incorrect message IDs, causing silent translation fallback and client/server mismatch.
In Next.js 16.3.6 on Vercel, background cache regeneration started during streaming is not tracked by waitUntil, causing it to be aborted when the serverless function exits, resulting in failed revalidations.
When a server component calls notFound() inside a dynamic route, the SSR response contains an empty HTML shell with <html id="__next_error__"> instead of rendering the root layout and not-found.tsx content. This occurs because the not-found error is thrown during server rendering and caught by the outer app-render catch, which generates a minimal error document rather than re-rendering the tree with the not-found boundary active.
Client-side navigation to ISR pages can serve stale RSC payloads from browser cache without contacting the server, leading to mixed module versions and runtime errors after redeployment.
Google Fonts occasionally returns extensionless URLs with a format('woff2') hint. Next.js font loaders assume a file extension in the URL, causing webpack to crash with a null regex match and Turbopack to split the URL query on '&', resulting in intermittent build failures.
In Next.js 16.3.6 and 16.3.8, a render error during an in-flight server action causes the shell to suspend repeatedly, eventually throwing minified React error #482 and replacing the page with 'This page couldn't load' instead of rendering error.js.
In Next.js dev with Turbopack, using next/dynamic to load a component that contains a plain import() causes the page HTML to reference a chunk that the dev server never emits, resulting in 404 errors on every page load. This affects both App Router (preload link) and Pages Router (script src). The actual dynamic import still works because the emitted loader chunk has a different hash.
The `next info` command incorrectly displays the latest stable version instead of the actual installed canary version, misleading users about their Next.js version.
In App Router-only builds, requesting a dynamic route with a malformed percent-encoded segment (e.g. /items/%E0%A4) triggers a DecodeError during route matching. Base-server attempts to render the Pages Router /_error page with a 400 status, but that page does not exist in builds without any Pages Router routes, resulting in a bare 500 response.