Recover from blocking routes under Instant Navigation lock when deployed (#95227)
The Instant Navigation feature locks navigation to a route's static
shell so you can inspect the prefetched shell before any dynamic content
streams in. It is controlled by a cookie: in development the Instant
Navigation DevTools set and clear it for you, and in any environment you
can drive it by hand by setting the cookie in the browser's DevTools. A
blocking route (one with a Suspense boundary above `<body>`, or `export
const instant = false`) has an empty static shell, so when you do a full
page load of such a route while the cookie is set, that empty shell is
served as a blank document with no way to release the lock, and every
reload renders the same blank shell and leaves you stuck.
Previously the handler threw for an empty shell. In development that
surfaces as the error overlay, which is what we want, and the catch
clears the cookie so a reload recovers. It did not recover when
deployed: the cookie could only be cleared via `Set-Cookie`, which
cannot take effect there because the empty shell is served from the ISR
cache with its response headers already committed, so the user stayed on
the blank shell across reloads. In `next start` it recovered but
rendered only a generic "Internal Server Error" page.
With this change a deployed blocking route recovers. For the empty-shell
case we serve a minimal document whose inline script clears the cookie
client-side, so the next full page load renders the route normally; we
clear it from the document rather than with `Set-Cookie` because the
headers are already committed when the shell is served from the cache.
Development still throws so the error overlay shows. As a secondary
improvement, `next start` now serves that same document with a readable
explanation instead of the generic "Internal Server Error" page.
The blocking-route test now asserts the user-facing outcome (after a
reload the route renders normally) rather than transport details such as
the status code and `Set-Cookie`, which legitimately differ across dev,
`next start`, and deploy, and it now runs on deploy as well.
next.js
f14048b6 - Recover from blocking routes under Instant Navigation lock when deployed (#95227)
