next.js

29464ac5 - [test] Reorder `hmr-intercept-routes` test to avoid a reload/refresh race (#95134)

[test] Reorder `hmr-intercept-routes` test to avoid a reload/refresh race (#95134) The `hmr-intercept-routes` test created the `@intercept` parallel-route slot files before editing the root layout to render the slot. Adding a new parallel-route slot is a structural change that forces a full page reload, and that reload raced with the Fast Refresh for the layout edit. Under load the client's `reloading` guard could drop the in-flight refresh, so the new slot never reached the browser and the test timed out waiting for `#default-intercept`, [failing 30-40% of the time in CI](https://app.datadoghq.com/ci/test/runs?query=test_level%3Atest%20%40git.repository.id%3A%22github.com%2Fvercel%2Fnext.js%22%20%40test.name%3A%22hmr-intercept-routes%20should%20update%20intercept%20routes%20via%20HMR%22%20%40test.status%3A%28fail%20OR%20pass%29&agg_m=count&agg_m_source=base&agg_t=count&currentTab=overview&eventStack=&fromUser=false&index=citest&start=1781719381980&end=1782324181980&paused=false). <img width="428" height="176" alt="Screenshot 2026-06-24 at 20 04 01" src="https://github.com/user-attachments/assets/0272886e-dd75-4dbd-bd8c-b26ee8f40082" /> This change edits the layout first, so the `intercept` slot is already rendered as an undefined, no-op prop before the slot files exist. Creating the slot files afterward triggers the structural reload, and because the layout already renders the slot, that reload serves the complete updated route tree in a single fetch with no competing Fast Refresh. The server always resolved the route correctly; only the browser-side delivery was racy.