Affected version
Reports that share this version, grouped in one feed.
In Next.js production builds, when a Server Action writes a cookie and calls revalidatePath, and the page segment has an async layout and a loading.js boundary, the resulting transition can get stuck with suspendedLanes=512 and pingedLanes=0, causing the UI to never update. This is a stochastic bug affecting versions 16.2.x and 16.3.x.
A client disconnecting during /_next/image optimization causes the response generator promise to never settle, permanently poisoning the cache key for all subsequent requests on self-hosted Next.js (next start/standalone).
When Next.js is started with `-H 127.0.0.1` behind a reverse proxy that sets `X-Forwarded-Proto: https`, middleware rewrites targeting the same server are incorrectly treated as external and proxied over the network using the `https` scheme against the plain-HTTP port, resulting in `write EPROTO ... wrong version number` and a 500 response. The root cause is an asymmetric normalization of loopback hostnames between the router server's `initUrl` and the URL exposed to middleware.
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.
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.