Repository navigation
fix(hono): Name routes without c.req.matchedRoutes - #25454
Merged
Merged
Conversation
Hono 5 removes c.req.matchedRoutes and c.req.routePath. The vendored HonoRequest type required both, so app.use(honoMiddleware(app)) failed with TS2769 on Hono 5. Make matchedRoutes optional and drop routePath, which the SDK does not read. Add Vitest type tests against Hono 4 and a pinned Hono 5 release candidate, a type check of the SDK calls in the Hono 4 E2E apps, and a lint rule that keeps hono imports out of @sentry/server-utils. Pin the hono devDependency of @sentry/hono to 4.13.9, so the package no longer builds against the hoisted version by chance. Refs #25223 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
size-limit report 📦Compared: 5b3325a (PR test merge using develop at 4316c26) Against: 4316c26 (develop) · base run #65429 ✅ Baseline matches: this diff contains only this PR's changes.
|
The hono devDependency of @sentry/hono (4.13.9) and the integration tests (^4.13.7) resolved to two Hono copies. Their HonoRequest types differ by a unique symbol, so sentry(app) did not type-check in the bun and cloudflare integration tests, and yarn dedupe-deps:check failed. Resolve both to 4.13.9. Refs #25223 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The Context hook and wrapSubAppMiddleware each had their own copy of the rule that tells middleware from route handlers. Move the rule to getMiddlewareFlags() and check the shape of the match result entries before the hook reads them. No behavior change. Refs #25223 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Hono 5 removes c.req.matchedRoutes, so every request was named "GET ". It also restores c.req.routeIndex after next(), so the Sentry middleware can no longer see which handler responded. Read the match result through the getter that hono/route uses, and let each route handler record its routeIndex when it starts. A request with no matched route keeps the runtime's span name. On Hono 4 the names stay the same, except where the old rule picked a later catch-all, for example for a route handler declared with an unused next parameter. Refs #25223 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Name the span when a route handler starts, so events captured in the handler get its route. - Fall back to the first matched route handler, then to a middleware path. A request without a route keeps the runtime name. - Wrap route handlers only when one of them declares `next`.
# Conflicts: # packages/hono/package.json # yarn.lock
# Conflicts: # packages/server-utils/src/integrations/hono/honoIntegration.ts
s1gr1d
added a commit
that referenced
this pull request
Oct 23, 2026
Preparation for #25454. No behavior change. - The Context hook and `wrapSubAppMiddleware` had their own copies of the rule that tells middleware from route handlers. Both now call `getMiddlewareFlags()` - The hook checks the shape of the match result entries once (`isMatchedHandlerList()`), instead of optional chaining at each step Ref #25223 --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
# Conflicts: # packages/hono/test/shared/middlewareHandlers.test.ts # packages/server-utils/src/integrations/hono/createHonoMiddleware.ts # packages/server-utils/src/integrations/hono/middlewareHandlers.ts
# Conflicts: # packages/hono/package.json # packages/server-utils/src/integrations/hono/honoIntegration.ts # packages/server-utils/src/integrations/hono/matchResult.ts # pnpm-lock.yaml
Contributor
Optional E2E testsSome optional checks were not successful. They do not block the merge. 8 not successful, 49 successful. See the run.
Successful checks
|
s1gr1d
requested review from
chargome,
isaacs,
mydea and
nicohrubec
and removed request for
a team
October 27, 2026 13:57
isaacs
approved these changes
Oct 28, 2026
isaacs
left a comment
isaacs
left a comment
Member
There was a problem hiding this comment.
There's a regression on Hono 4, but otherwise the changes here are all improvements. Fix that and this is good to land, imo.
| return current.path; | ||
| // Hono runs the first matched route handler first. If a middleware returned early, it is the one that | ||
| // would have run. | ||
| const firstRouteHandler = routes.find((_route, i) => !middlewareFlags[i]); |
Member
There was a problem hiding this comment.
Subtle regression here, this will make a global middleware with arity < 2 name every route GET /*
firstRouteHandler trusts middlewareFlags, which comes from arity for ALL routes. A .use() middleware whose declared arity is below 2 is classified as a route handler. Examples: (c, next = noop) => ... (default params do not count toward length), (c, ...rest) => ..., or a third-party wrapper that forwards ...args. Because app.use(mw) registers path /* and comes first in the match list, it becomes the "first route handler" for every request.
I confirmed this on Hono 4.13.11:
app.use(createHonoRequestMiddleware({ runtime: 'node' }));
app.use((c, ...rest: any[]) => rest[0]());
app.get('/users/:id', c => c.text('u'));
// GET /users/1 -> setTransactionName('GET /*'), expected 'GET /users/:id'On develop, the old code read routes[routeIndex] at response time. On Hono 4 that index lands on the /users/:id handler, so it named the request correctly. This PR removes the response-time rename, and wrapRouteHandlers does not wrap here (no route handler "declares next" by arity, because the misclassified middleware has arity 1), so nothing corrects the provisional name. The misclassification itself existed before (it affects middleware span wrapping too), but its effect on the transaction name is new, and it is silent: every transaction in the app collapses to one name.
Suggestion: Always wrap the route handlers when the match result is available (drop the canPassOn shortcut in wrapRouteHandlers). The misclassified middleware then records its index first, the real handler records its index later, and the final name is correct. The cost is one Proxy call per route handler call.
Or, another possibility if it's easier, in resolveRouteName, we could skip a /* route as the provisional pick when a more specific route handler follows it in the list.
Either way, might be good to add a unit case for an arity-1 global middleware.
Member
Author
There was a problem hiding this comment.
Good catch, thanks! I fixed that.
I went with your first idea, but slightly different: we now wrap when two or more route handlers matched (when just one matches, it's the response handler), so arity is not the deciding factor.
Added unit cases (rest params, default next, path middleware) and an integration case. They all failed before the fix.
Known gap: Hono < 4.8 with the manual setup has no match result, so it would still show GET /*. Almost nobody uses that version, so I left it. Download numbers: https://npm-burst.com/package/hono/
chargome
approved these changes
Nov 3, 2026
s1gr1d
commented
Nov 10, 2026
Member
Author
There was a problem hiding this comment.
This is the most important file
Member
Author
There was a problem hiding this comment.
Also contains important changes.
| * so this looks for a symbol getter that returns a match result. | ||
| * https://github.com/honojs/hono/blob/v5.0.0-rc.1/src/helper/route/index.ts#L32-L34 | ||
| */ | ||
| export function getMatchedHandlers(context: Context): MatchedHandler[] | undefined { |
Member
Author
There was a problem hiding this comment.
We find the match result through an unexported Symbol getter on the request prototype. This is just like hono does it.
| { method: 'get', path: '/users/me', name: 'GET /users/me', route: '/users/me' }, | ||
| { method: 'get', path: '/users/42', name: 'GET /users/:id', route: '/users/:id' }, | ||
| { method: 'get', path: '/users/42/posts', name: 'GET /users/*', route: '/users/*' }, | ||
| { method: 'get', path: '/early/1', name: 'GET /early/:id', route: '/early/:id' }, |
Member
Author
There was a problem hiding this comment.
in case the middleware returns early, we still get a parametrized route.
51 tasks done
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
On Hono 5, every request got the span name
GETand an emptyhttp.route. With this PR, names look the same as on Hono 4:GET /users/:id, withhttp.routeset to/users/:id.Why they broke:
c.req.matchedRoutes.composeresetsc.req.routeIndexafternext()(honojs/hono#4424), so the Sentry middleware cannot see which handler responded.How the name is built now:
hono/routeuses (matchResult.ts).next(). Rest parameters and a defaultnexthide it.Small changes on Hono 4 too: events captured in a handler get that handler's route (not a later catch-all), and a 404 keeps the runtime name
GETinstead ofGET /*.Refs #25223