Astro.locals, set in middleware, available on 404 page in dev mode but not in production mode

[xriter]

What version of astro are you using?

2.10.12

Are you using an SSR adapter? If so, which one?

Node

What package manager are you using?

npm

What operating system are you using?

Mac

What browser are you using?

Safari

Describe the Bug

After some previous bugs around the 404 page have been solved, I still experienced problems with my 404 page not rendering. I now found the reason: another bug.

When using middleware.ts to set Astro.locals, you can then use those values in the 404.astro page when it's in dev mode. But when in production mode, those values are undefined. (This caused the page to crash without me knowing, resulting in a blank 404 page).

👉 So in short: the behaviour of Astro.locals availability in 404.astro between dev and production mode is inconsistent.

This problem started from Astro 2.9.7. Before that it worked as expected.

To repro and see the difference between the 2 modes, go to the stackblitz link.
Then first run npm run dev and then npm run build && npm run preview

Dev mode (the expected result):

Production mode:

(This is a continuation of the problem I first described in issue #8054, but turns out to be a separate bug.)

What's the expected result?

I expect Astro.locals, set in middleware.ts to be available in 404.astro in production mode.

Link to Minimal Reproducible Example

https://stackblitz.com/edit/github-trfvka-twqzu5?file=src%2Fpages%2Findex.astro

Participation

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

[lilnasy]

Might be related #7881

[lilnasy]

@xriter Does middleware work at all for 404?

If not, this is the same issue I brought up in #7881.

[xriter]

I added some console logs to the middleware in the stackblitz.
The middleware gets called in dev mode, but not in production mode.

[xriter]

#7881 is older, referring to Astro 2.9.6. In that version the middleware DID get called for custom 404 pages (in both modes), but not for the default 404 page (in both modes). That is what that issue was about: the default 404.

I guess the whole 404 behaviour changed since then, but not for the better.

[lilnasy]

Thanks for opening this issue and confirming!

To clarify, this issue is not a duplicate of 7881. When I reported it in that issue, I should've created another issue instead.

[lilnasy]

Is the workaround possible in your case?

[xriter]

Tried it in: https://stackblitz.com/edit/github-trfvka-vfy3p1?file=src%2Fpages%2F%5Bslug%5D.astro
I guess that works.
It doesn't fix the root problem though.
Are there any downsides of using [slug].astro instead of 404.astro that I can't think of right now?

[lilnasy]

I don't think there is.

You may already be using a slug route, but in that case, I think 404.astro never gets matched anyway.

[ematipico]

This fix will be released as part of Astro 3.0