Adapters not following the route priority ordering after build

[lschierer]

What version of starlight are you using?

0.24.1

What version of astro are you using?

4.10.2

What package manager are you using?

pnpm

What operating system are you using?

Mac

What browser are you using?

Chrome

Describe the Bug

I've found what I think is a routing bug that I'm not sure if its becuse of the starlight integration or not. (If not, I'm happy to refile this with Astro itself) I've got a minimal reproduction at https://stackblitz.com/edit/github-lsqplx

if you run this with npm run dev the two links I put on the home page, "broken" and "works" are identical (they should be). But if you run it as a node site as if deployed with npm run build && node dist/server/entry.mjs then they differ, in that the one that is pre-rendered ("works") works and the one marked to be dynamic ("broken") gets intercepted by starlight instead.

Ideally both should work the way the one I've labeled "works" does. Minimally they should work the same whether I run npm astro dev or node dist/server/entry.mjs

note that I've first hit this on my actual repository using pnpm on OSX and the AWS adapter whereas the Stackblitz uses npm presumably on Linux with (obviously) the node adapter. So the bug is

• not package manager specific
• not operating system specific
• not adapter specific

Link to Minimal Reproducible Example

https://stackblitz.com/edit/github-lsqplx

Participation

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

[lschierer]

I was hoping, when I saw the changelog, that Astro 4.10.2 would have fixed this, but no such luck. I have updated the version numbers.

[Fryuni]

Hey, @lschierer! Thanks for the report.

This is not a problem on Starlight. It is partly on Astro core and the Node adapter (on every adapter). The problem can be reproduced without Starlight: https://stackblitz.com/edit/github-js5zvj

What is happening is that the routing priority rules used on the dev server and on the build do not match the wiring in the adapter. The adapter presents all pre-rendered content first and looks for dynamic routes only when no pre-rendered content is found, which should be the fourth rule, not the first.

I'm gonna transfer this issue to the core repo so we can track it there 😄

You mentioned that the original problem was on an AWS adapter. You'd probably have to open an issue with them to either fix the adapter so it follows the priority rules or document the rules they follow. Astro doesn't have a first-party AWS adapter.

[lschierer]

I figured I had even odds of being wrong either way, thanks for transferring the report to the right place.

[Fryuni]

Thinking a bit more about this, it falls into a situation that it was supposed to show you a warning about the conflict (it is one of the known false negatives at the moment) and in the future we plan for that to be an error (essentially you can't build a website where a page is entirely discarded).

Fixing the page generation within the astro package should fix this for all adapters and provide a proper warning that it is happening.

[lschierer]

oh.  I will have to think of something else then because I would be discarding one page in either case, evenif the adapters processed the rules as I expected.  I am purposely overloading the route because then starlight includes it in the sidebar nav menu automatically.  its a neat trick when the specificity rules are honored by the adapters.

Jun 15, 2024 14:19:44 Luiz Ferraz @.***>:

Thinking a bit more about this, it falls into a situation that it was supposed to show you a warning about the conflict and in the future we plan for that to be an error (essentially you can't build a website where a page is entirely discarded).

Fixing the page generation within the astro package should fix this for all adapters and provide a proper warning that it is happening.

— Reply to this email directly, view it on GitHub https://github.com/withastro/astro/issues/11266#issuecomment-2170468503 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQ67LFLZUN3BILLXV3XATDZHSAT7AVCNFSM6AAAAABJLOWKKOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNZQGQ3DQNJQGM . You are receiving this because you authored the thread. https://github.com/notifications/beacon/AAQ67LFRMBETD6BAFNGZY3LZHSAT7A5CNFSM6AAAAABJLOWKKOWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTUBL24JO.gif Message ID: @.***>