Starlight Middleware (i18n): headers undefined

[vague needle]

I combined the Starlight Blog and Starlight Sidebar Topics plugin which works fine but poses one challenge:
Every blog route that gets injected by the plugin has no matching topic. So I'm trying to solve this problem by creating a Starlight Middleware that sets the topic frontmatter to the blog topic id (unlisted pages).

However I get the error Cannot read properties of undefined (reading 'headers') when visiting the site (as you can see in the image).

Do you (@short thistle or @ancient estuary) have any idea why this could be?

You can play around with the project here: https://github.com/trueberryless/starlight-blog-plus-starlight-sidebar-topics-dropdown/tree/0-32

(You can also easily switch between Topics Dropdown or normal Topics plugin by just changing the name of the plugin to add to Starlight, both are installed)

This is currently my middleware.ts:

import { defineRouteMiddleware } from "@astrojs/starlight/route-data";

export const onRequest = defineRouteMiddleware((context) => {
  try {
    const { entry, id } = context.locals.starlightRoute;

    console.log(id);

    if (id.startsWith("/blog/")) {
      entry.data.topic = "blog";
    }
  } catch (e) {
    console.log("Skipping non-Starlight route");
  }
});

[vague needle]

Solved: next call was missing, updated middleware:

import { defineRouteMiddleware } from "@astrojs/starlight/route-data";

export const onRequest = defineRouteMiddleware(async (context, next) => {
  try {
    const { entry, id } = context.locals.starlightRoute;

    if (id.startsWith("blog")) {
      entry.data.topic = "blog";
    }
  } catch (e) {}
  return next();
});

[ancient estuary]

Huh, that seems odd that it would solve it.

next() makes a difference when called before your own code (by letting you wait for other middleware to run) but calling it last like you do here should behave exactly the same as not calling it at all.

You also shouldn’t need the try/catch I don’t think — inside a route middleware starlightRoute should always be accessible. Were you seeing errors that required the try/catch block?

[vague needle]

Okay, before answering and thinking again why I added try/catch let me answer the next topic:
I was looking at the middleware from my phone and suddenly realized that I was completely missing the next call after reading docs again...
I too was sure that I must add the awaited call before the code (which makes a lot of more sense) but then there was a problem on the index page of the repro. I cant remember exactly, should I create a branch with the only change being moving the next call before and await it instead of returning of course? Let me know!

[vague needle]

Let me quickly try again. If I remember correctly, there was an error, but it made sense: Because Starlight Blog injects new routes (alto the have <StarlightPage>), hmmm, maybe I dont need them, let me try, be right back

okay, I did remember correctly, there was an error without try/catch:

gonna send the link to a stackblitz asap

Okay, so here the three version:

• Working (as above): https://stackblitz.com/~/github.com/trueberryless/starlight-blog-plus-starlight-sidebar-topics-dropdown/
• without try/catch: https://stackblitz.com/~/github.com/trueberryless/starlight-blog-plus-starlight-sidebar-topics-dropdown/tree/delete-try-catch
• move next call to top: https://stackblitz.com/~/github.com/trueberryless/starlight-blog-plus-starlight-sidebar-topics-dropdown/tree/move-next-call

Moving next to top makes it throw headers is undefined error on "root page" (/), like the initial issue...

If something is odd and I should provide more repros or anything, feel free to ping me please!

[ancient estuary]

Hmm, very weird. I’ll take a look.

[vague needle]

@ancient estuary Did you find time for some investigation or any further infos? I also completely forgot about this weird middleware next call tbh... Maybe we should create an issue in the Starlight repo to keep track of it...

[ancient estuary]

Oh you’re right, in this repo it is also using src/middleware.ts

Could definitely be the issue!

It’s why I chose src/routeData.ts in the docs examples, but maybe we should make it clearer.

[vague needle]

yeah, I was wondering why it wasnt just middleware