Next.js
Published reports for this stack, with severity, affected version, and a direct path into each diagnostic.
When a modal is opened via interception over a page that is itself interceptable, performing a router.refresh() or revalidatePath causes the background route refresh request to incorrectly include the Next-Url header, leading to an intercepted response and an MPA fallback, resulting in a full page load and loss of client state.
When using MapLibre GL v6 with Next.js Turbopack, the generated worker file contains an import for 'maplibre-gl-shared-dev.mjs', but the emitted file has a hash suffix, causing the worker to fail with 'Worker failed to load'.
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.
Supabase Studio's database password inputs (Reset database password and new project database password) only set autoComplete="off", which password managers like LastPass ignore. This allows the user's Supabase account password to be autofilled into the database password field, creating a credential reuse vulnerability and potential accidental database password exposure.
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.
The @next/codemod agents-md command computes the docs root path relative to the current working directory rather than the directory of the `--output` AGENTS.md file. In monorepos where the output file is at a different location (e.g. repo root) and Next.js is installed only in a workspace package, the generated root path is broken, causing agent tools to read nonexistent documentation paths.
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.