default.tsx parallel routes are using the loading.tsx from the parent route instead of the one from the parallel route

[nuclei272]

Link to the code that reproduces this issue

https://github.com/nuclei272/parallel-route-loading-ui-bug

To Reproduce

1. Go to https://codesandbox.io/p/github/nuclei272/parallel-route-loading-ui-bug/main.
2. Click on the button to navigate to "/comments" route.
3. Click on the button to do a hard refresh.

Current vs. Expected behavior

When you click to hard refresh, you'll see that the header and sidebar parallel routes (@header and @sidebar) will incorrectly displays "Loading Children...", which is the loading.tsx on the parent route /. The children page displays the loading.tsx correctly and the route /comments is also displaying it correctly.

The expected behaviour would be to loading the corresponding loading.tsx on @header and @sidebar parallel routes as seen when we first load the page on the root route /.

Provide environment information

Operating System:
  Platform: win64
  Arch: x64
  Version: Windows 11 Pro
  Available memory (MB): 15694
  Available CPU cores: 4
Binaries:
  node: 21.2.0
  yarn: 1.22.21
Relevant Packages:
  next: 14.3.0-canary.49 // Latest available version is detected (14.3.0-canary.49).
  eslint-config-next: 14.2.3
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 5.4.5
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Parallel & Intercepting Routes

Which stage(s) are affected? (Select all that apply)

next dev (local), next build (local), next start (local), Vercel (Deployed), Other (Deployed)

Additional context

No response

[nuclei272]

I know I could add a suspense boundary to wrap the header on the layout.tsx file for example, but then I can't access searchParams on layout.tsx, so it must be a page.tsx in a parallel route... Does anyone know a way around this? Hopefully it's gonna be fixed and the default pages will show the loading state from the parallel route instead of the loading state from the parent main route.

Edit: A way around this would be to wrap the content inside the @header and @sidebar parallel routes with the suspense, but then, I don't see why not allow having the loading.tsx page to show the loading state.

[dalechyn]

@leerob friendly bump