Server Action Update Never Commits: A Transition Lane Stays Suspended And Is Never Pinged

Next.js's router reducer handles the 'refresh' action triggered by revalidation using a React transition. When the refresh involves an async layout that re-suspends, and the RSC payload's thenable has already been resolved (or is cached), React's ping callback is not attached to the thenable, so the suspended transition lane is never pinged and remains stuck. This stems from a design flaw in how the router reducer reuses or caches the resolved RSC data/chunks between the action response and the subsequent refresh, bypassing React's normal thenable ping mechanism.

1. Create a Next.js app with App Router and a Server Action that writes a cookie and calls revalidatePath. 2. Add a nested segment (e.g., app/(app)/decks/page.jsx) with an async layout at the parent boundary (app/(app)/layout.jsx) that awaits every request. 3. Add a loading.js at the boundary (app/(app)/loading.jsx) to create a Suspense boundary. 4. Build the app with `next build` and run it in production. 5. Trigger the Server Action repeatedly under CPU load (e.g., using Playwright with high parallelism and busy loops) until the page fails to update. 6. Inspect the FiberRoot: pendingLanes=512, suspendedLanes=512, pingedLanes=0 indicates the bug.

This hotfix discards cached RSC data on every refresh, which may increase network requests and slow down client-side navigations, especially on pages with heavy data. It may also interfere with prefetching or other optimizations that rely on cache reuse. Rollback should be immediate if any performance regression is observed. Additionally, this patch has not been tested under all concurrent and multi-threaded scenarios typical of Next.js production deployments; it is advised to verify with the project's test suite and consider upgrading to Next.js 16.4.0 or later, where the underlying issue appears to be resolved.