Route middleware is skipped when `~getMiddleware` is overridden

[pi0x]

Summary

When an app overrides ~getMiddleware, per-route middleware is silently skipped — the route handler still runs, but its own middleware never does.

Why

createDispatcher (src/h3.ts) has two paths, and they disagree about who supplies route middleware:

• Default path — the final handler is routeHandler(route), which composes route.data.middleware in front of route.data.handler.
• Compat path (taken when ~getMiddleware is overridden) — the final handler is the bare route?.data.handler || NoHandler, so route middleware is only present if ~getMiddleware happened to include it.

The default ~getMiddleware does include it, so an override that delegates to super is fine. But an override that returns its own list — which is what the signature invites — drops route middleware with no error.

Repro

const seen: string[] = [];
const app = new H3();
app.use(() => { seen.push("global"); });
app.get("/x", () => "ok", { middleware: [() => { seen.push("route"); }] });

// any custom ~getMiddleware that doesn't re-add route.data.middleware
(app as any)["~getMiddleware"] = function () { return this["~middleware"]; };

await app.request(new Request("http://localhost/x"));
// seen === ["global"]   — expected ["global", "route"]
// response body is still "ok", so the handler ran without its middleware

Impact

Mainly integrators that override ~getMiddleware for per-event middleware (nitro is the documented reason the branch exists). If per-route middleware is used for auth or validation, it stops being enforced while the route keeps serving.

Note

Found while reviewing route rules — not a rules bug, this reproduces with plain H3. Raising it separately since ~getMiddleware is part of the internal surface downstream depends on.

[lazerg]

I looked into this. The compat path isn't an oversight, it's the pre-#1475 contract kept as-is: before "perf(middleware): precompose middleware chains" (#1475), ~getMiddleware was the single source of truth for all middleware, route-level included. That PR added the fast path for the default case and left the old behavior in place as the fallback for overrides.

The suggested fix (compose route.data.middleware in the compat branch too) does resolve the repro, but it double-runs route middleware for Nitro's own generated app code, which already re-adds it when building its list:

if (route?.data?.middleware?.length) {
  middleware.push(...route.data.middleware);
}

Tested both cases against a build with the fix applied:

override	before	after
repro (drops route middleware)	["global"]	["global","route"]
Nitro-style (re-adds route middleware)	["global","route"]	["global","route","route"]

So it trades a silent skip for a silent double-run, and route middleware is often auth or rate-limiting, so running it twice isn't obviously safer than not running it. The mirror fix (always compose route middleware in the handler, drop it from the default ~getMiddleware) breaks Nitro the same way, since Nitro doesn't call super.

Feels like this needs a real call on who owns route middleware in an override, ~getMiddleware or the handler, rather than a one-line patch. Didn't want to open a PR that quietly regresses the Nitro path without that decision first.