Add failing test for allow-runtime routes under the Instant Navigation lock#96029
Add failing test for allow-runtime routes under the Instant Navigation lock#96029gaojude wants to merge 1 commit into
Conversation
Stats from current PR🟢 1 improvement
📊 All Metrics📖 Metrics GlossaryDev Server Metrics:
Build Metrics:
Change Thresholds:
⚡ Dev Server
📦 Dev Server (Webpack) (Legacy)📦 Dev Server (Webpack)
⚡ Production Builds
📦 Production Builds (Webpack) (Legacy)📦 Production Builds (Webpack)
📦 Bundle SizesBundle Sizes⚡ TurbopackClient Main Bundles
Server Middleware
Build DetailsBuild Manifests
📦 WebpackClient Main Bundles
Polyfills
Pages
Server Edge SSR
Middleware
Build DetailsBuild Manifests
Build Cache
🔄 Shared (bundler-independent)Runtimes
📎 Tarball URLCommit: 2f9edc5 |
Failing test suitesCommit: 2f9edc5 | About building and testing Next.js
Expand output● instant-navigation-testing-api › renders full prefetch content instantly when the target also allows runtime prefetching
Expand output● instant-navigation-testing-api › renders full prefetch content instantly when the target also allows runtime prefetching
Expand output● instant-navigation-testing-api › renders full prefetch content instantly when the target also allows runtime prefetching
Expand output● instant-navigation-testing-api › renders full prefetch content instantly when the target also allows runtime prefetching
Expand output● instant-navigation-testing-api › renders full prefetch content instantly when the target also allows runtime prefetching
Expand output● instant-navigation-testing-api › renders full prefetch content instantly when the target also allows runtime prefetching
Expand output● instant-navigation-testing-api › renders full prefetch content instantly when the target also allows runtime prefetching
Expand output● instant-navigation-testing-api › renders full prefetch content instantly when the target also allows runtime prefetching |
|
Traced the mechanism by instrumenting the published canary.92 client in the external repro (dev mode, console checkpoints). Chain:
So there are two layers: an intended semantic shift (full prefetch superseded on partial-prefetching routes) and a bug in the replacement path (the unresolved |
|
Production impact without the lock, same repro, measured by counting dynamic RSC requests (rsc header, no prefetch header) between the link click and the marker paint after the prefetch settled: canary.85 paints with 0 dynamic requests (served from the prefetched cache), canary.92 paints only after 1 fresh dynamic request. So outside the testing API the page still renders and nothing errors, but the navigation is no longer instant: the full link prefetch on an allow-runtime route no longer produces data the navigation can use. The instant() hang is the loud version of this silent regression. |
Adds a failing test demonstrating a regression from #95415: a route that opts into runtime prefetching (
export const prefetch = 'allow-runtime') can no longer commit a navigation from a full link prefetch while the Instant Navigation lock is held.The new fixture page is a copy of
full-prefetch-targetplus that single export, and the new test is a copy of the sibling full-prefetch test pointed at it. The sibling passes and the new test times out; under the lock the navigation commits nothing at all: not the prefetched content, notloading.tsx, and the source page stays on screen.Reproduces in both dev and start modes. Bisected against published packages in an external repro: passes through
16.3.0-canary.87, fails from16.3.0-canary.88(the release containing #95415), under webpack as well as Turbopack. Request logs there show the router re-issuing prefetch requests it had already completed (identical_rsccache-bust hashes) and then waiting on the dynamic request the lock withholds. v0 hit this on its canary bump and skipped the affected app test until this is fixed (vercel/v0#27128).