next.js

b2f564dc - Await reused in-flight prefetch entries under Instant Navigation lock

Await reused in-flight prefetch entries under Instant Navigation lock A locked instant() navigation could time out flakily on routes that use runtime prefetching (e.g. `allow-runtime` pages). The navigation reads the segment cache only after its prefetch drains, but the prefetch only awaits the entries it spawned itself. When an earlier prefetch in the scope had already started a more-specific runtime upgrade (a `PPRRuntime` page entry) that was still in flight, the navigation reused that entry without tracking it, drained without waiting for it, and read while it was still pending. The read then fell back to the less-specific fulfilled `RuntimeShell` entry (the static shell with no resolved value), so the awaited content never surfaced and the test timed out. The race only lost under CPU contention, which is why it reproduced in the prod flake-detection job on slow containers but almost never locally. This change tracks an in-flight entry at the point the navigation reuses it. In `readOrCreateSegmentCacheEntry`, when a locked navigation reuses an existing `Pending` entry it did not spawn, it now registers that entry on the navigation's prefetch via `trackNavigationLockPrefetchEntry`, so the prefetch awaits it before the navigation reads. The read then finds the resolved entry rather than the shell. The fix is content-neutral: the entry is looked up by the concrete vary path, so it is whatever the navigation would read at that key regardless. Tracking only controls whether the navigation awaits the entry now versus suspends on it during render, so it cannot surface an entry the navigation would not otherwise read, and it leaves session ownership untouched (so reads still never miss). Tracking is deduped, so reusing an entry the navigation already spawned is a no-op. This also lowers the per-action timeout in the `instant-navigation-testing-api` test suite to below jest's test timeout, so a future stalling `waitFor` fails with its own locator (naming the element that never appeared) instead of a bare test-level timeout that hides which assertion hung. That edit also marks the suite as changed, so CI's flake-detection job re-runs the previously flaky runtime-prefetch tests and confirms they are now stable.