Framework
Reports that share this framework, grouped in one feed.
When prefetching the index page of an optional catch-all dynamic route, the client caches the __PAGE__ entry under a fallback slug. Subsequent navigation to a sibling dynamic path reuses this cached entry without issuing a new request, causing the wrong page content to be displayed.
In Next.js production builds (App Router), router.refresh() fails to trigger a server round-trip when the current page was streamed and the URL contains a query string. This causes stale UI after mutations on filtered list pages, with no fetch initiated. The issue is present across multiple versions, with 16.2.12 only affected for query-string URLs, and 16.3.5+ affected for all streamed pages. A fix requires forcing cache invalidation for the current URL during refresh.
Next.js dev server (Turbopack) fails to match routes that are children of a dynamic segment nested inside route groups, returning instant 404 for the entire session. The issue is probabilistic, occurs under module graph load, and is repaired by any file event under app/. Production builds are unaffected.
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.
Next.js middleware can return a response with a relative Location header (as allowed by HTTP spec), but the internal adapter passes this value directly to the NextURL constructor, which requires an absolute URL, causing an 'Invalid URL' error.
In Next.js 16, lowering watchpack's aggregateTimeout from 200ms to 5ms causes the dev server's initial page scan to fire aggregation callbacks before the scan completes. The first partial aggregation builds the dynamic route table from an incomplete page list, so dynamic pages-router routes return 404 until a later aggregation rebuilds it.
Starting with 16.3.8, the Next.js image optimization server fetches remote images using ImageHttpAgent/ImageHttpsAgent without proxyEnv, causing direct connections that ignore HTTP_PROXY/HTTPS_PROXY and global undici dispatchers. In proxied environments, all remote image requests time out with 504.
When a client component inside a Suspense boundary uses synchronous IO (e.g., Math.random or Date.now) during server rendering, the resumed segment omits the host elements rendered before the sync IO call. This causes a hydration mismatch (React error #418) and the boundary's fallback is replaced with an incomplete subtree.
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.
When a module using next/dynamic is imported by both Pages Router and App Router, ReactLoadablePlugin writes the App Router webpack module id into react-loadable-manifest.json, causing Pages Router client bundle to request the wrong dynamic chunk id and fail hydration with React error #418.
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.
When multiple SWC plugins are configured and Turbopack's persistent file system cache is enabled (default since Next.js 16.3.0), a restored cache can pair plugin modules with the wrong configuration objects, causing SWC plugin panics and build/dev failures.
File-system-cache `set()` omits the `.rsc` file for PPR routes, causing `get()` to treat the entry as missing after restart or eviction. This results in fallback shell re-rendering and stale RSC payloads for client navigation, leading to data inconsistency.
When a route is marked `dynamic = 'force-dynamic'`, fetches with `next: { revalidate: false }` are treated as uncached (revalidate: 0) due to a truthiness check in patch-fetch.ts, so each request hits the origin instead of using the Data Cache.
In Next.js 16.4.0 dev with Turbopack, Pages Router pages crash during hydration because required client modules are not included in any chunk. The regression was introduced by #97664, which seeded availability info from the _app chunk group into page chunk groups; in dev each entry has its own module graph, so availability items from _app are wrongly treated as already available, causing modules like a-page-only and b-boundary to be skipped.
On cold load with a delayed client component chunk, Next.js App Router repeatedly retries root hydration causing thousands of empty commits and significant main thread time. The issue is triggered by `useDeferredValue` calls in `Head` and `InnerLayoutRouter` that pass the current RSC value as the initial value even when no prefetch data exists during initial hydration. This leads to React scheduling deferred work that commits an empty tree, making hydration eligible to retry in a loop.
When a page calls notFound(), Next.js serves a minimal error shell (`__next_error__`) in the server HTML, omitting the root layout, `<html lang>` attribute, and the nearest not-found UI. This breaks accessibility, no-JS clients, and dynamic root layouts, and is inconsistent with the hydrated result. Affects App Router across multiple Next.js versions.
With default experimental.turbopackSharedRuntime enabled and cacheComponents true, the prerendered shell includes inline scripts for chunk bootstrap and performance timing that lack a nonce attribute, causing browser to block them under a strict nonce-based CSP. This prevents client-side hydration and interactivity.
When a native form POST (no JavaScript) targets a partially prerendered page, the Server Action executes but the response is only inlined Flight data with no HTML shell, leaving a blank page.
When Next.js is invoked from a directory other than the project root, relative imports in next.config.ts are resolved against the current working directory instead of the configuration file's own directory, leading to module resolution failures or loading incorrect files.
When Next.js is invoked from a directory other than the project root (e.g., `node app/node_modules/next/dist/bin/next build app`), relative imports in `next.config.ts` are resolved against `process.cwd()` instead of the config file's directory. This causes builds to fail with `Cannot find module` or silently load a wrong file if a similarly named file exists in the cwd. The issue affects the default SWC transpilation path and has been present since Next.js 15.0.0.
When building a Next.js project with next.config.ts from a working directory different from the project root, relative imports inside next.config.ts are resolved relative to process.cwd() rather than the config file's location. This causes module-not-found errors or, worse, silently loads a file with the same relative path from the current working directory, potentially applying unintended configuration.
After upgrading to Next.js 16.3.8, deployments that patch the existing .next directory in place (rather than recreating it) leave stale route-cache entries, causing 404s for CSS/JS assets. The root cause is that the route-cache key no longer includes a build identifier, so cached entries from the previous build remain valid after a new deploy.
Next.js 16.3.8 introduced a regression where the route-cache key no longer depends on the build ID. In non-atomic in-place deployments that patch the .next directory without clearing .next/server/route-cache, stale cache entries reference old hashed assets, causing 404s for CSS and JS files after deployment.
After an in-place deployment that patches the .next directory without clearing runtime caches, Next.js 16.3.8 and 16.4.0-canary.60 reuse stale route-cache entries, causing 404s for CSS and JS assets. The regression is linked to PR #99482, which changed the route cache key to no longer depend on the build output.
When using next/font/google with adjustFontFallback: false, the generated CSS still includes the automatic fallback font family, causing the fallback to always be applied. This is a regression from Next.js 14.
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.
When a client that has loaded a page from Next.js 16.1 performs a soft navigation (Link click) after the server is upgraded to 16.2, the old-format router state header sent by the client cannot be parsed by the new server, causing a 500 error. The issue only occurs when dynamic rendering is involved (e.g., using cookies()) because such requests always hit the server for RSC payload validation.
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.
Soft navigation breaks with a 500 error when a client that loaded a 16.1 app navigates after a server upgrade to 16.2, because the router state header format/encoding changed and the new server parser throws instead of falling back to a full navigation. The issue only occurs when at least one layout or page is dynamically rendered (e.g., uses cookies()).