Nested dynamic routes from content collections are not rendered

[Fryuni]

Astro Info

Astro                    v5.2.3
Node                     v22.12.0
System                   macOS (x64)
Package Manager          pnpm
Output                   static
Adapter                  @astrojs/vercel
Integrations             @astrojs/starlight

If this issue only occurs in one browser, which browser is a problem?

No response

Describe the Bug

I noticed that the some entries on IT docs (Inox Tools), like src/content/docs/inline-mod/lazy.md, are not being rendered. This triggered the link validator.
This problem seems be dependent on the full file path of the collection entries. On Vercel (that clones the project to /vercel/path0), this problem occurs on every time since 5.2.0 (even discarding cache). Locally it happens if I move the root folder around in my file system.

Inlining the glob loader used internally by Starlight with the exact same config doesn't solve the problem, but using ** as the pattern fixes it for some paths and breaks it for others. So it seems like we have a problem on the libraries we use to match the pattern or how we use them.

I thought it could be the [^_] exclusion, but using **/*.md also doesn't load that file.

Even weirder, another .md file in the same directory (src/content/docs/inline-mod/origins.md) is rendered correctly.

What's the expected result?

Pages for all content collection entries should be rendered.

Link to Minimal Reproducible Example

Couldn't make a minimal example, I'm investigating on my own project

Participation

• I am willing to submit a pull request for this issue.

[Fryuni]

Note on the priority: I added the P3 label cause I don't know yet whether this is an edge case caused by something I'm doing on IT or whether it is more widespread. It is hard to notice if you don't have an automation to detect it because the symptom is a page just disappearing. Not something you'd notice if it is not the page you are currently working on.

We can increase it if others are also facing this problem.

[Fryuni]

Initially I thought it started on 5.2.0 but I was comparing against 5.1.2 (that I was using earlier), not 5.1.10. Trying with each version in between I confirmed that this started on 5.1.5. It happens consistently since then and doesn't happen at all on 5.1.4.

[Fryuni]

The problem seems to be very sensitive.

Building from commit 1f9571b causes this error
Building from commit f00c2dd, the one just before it, works fine
So 1f9571b would seem to have introduced the problem. But it didn't even touch the astro package or any dependency.

It isn't random tho. Building multiple times with either give the same results, prior to that commit always work and starting from that commit always fails.

But then if I move one patch version of some unrelated package up or down, like a @astrojs/check that isn't even used during the build command, then the commit that was failing starts working and the commit that was working starts failing.

Running with the debugger also affects the outcome, so my guess is that there is a race somewhere such that changes to file hashes might affect the ordering (and thus the outcome) and that enabling the debugger would also affect it due to the extra instrumentation.

The debugger doesn't make it always work, there are combinations where it fails with the debugger. Exploring those I found that the files returned by the loader are correct even when the pages are not rendered, so the problem is somewhere else. I'll continue this later.

[Fryuni]

Figured this one out.

Astro caching things on node_modules/.astro is conflicting somehow with Turbo's cache in their latest version. The cache objects are being used as a key to the cache and as part of the cached objects, so loading the cache prior to a build changes the cache key itself and can load an incorrectly cached collections data layer.

File paths are part of the cache key and that is why things were working for some paths.

Deleting that folder after restoring the Turbo cache fixed the issue.