Skip to content

feat: expose the matched route pattern on the tracing context - #207

Merged
bjohansebas merged 3 commits into
pillarjs:masterfrom
logaretm:awad/tracing-route-pattern
Oct 23, 2026
Merged

bjohansebas merged 3 commits into
pillarjs:masterfrom
logaretm:awad/tracing-route-pattern

Conversation

@logaretm

@logaretm logaretm commented Oct 9, 2026 •

Copy link
Copy Markdown
Member

Tracing subscribers couldn't tell which route pattern matched a request, fixed by adding a route field to the express.router.request context, built on rawPath from #174.

I added tests for middleware, route handlers, route error handlers, mounted routers, and array paths where only one entry matches.

@logaretm logaretm changed the title docs: document reading the route pattern from the tracing context feat: expose the matched route pattern on the tracing context Oct 9, 2026
@bjohansebas

Copy link
Copy Markdown
Member

You can use my PR, no problem. You have commit access, so you can use the GitHub CLI to push to my branch

@logaretm

logaretm commented Oct 9, 2026 •

Copy link
Copy Markdown
Member Author

We can keep them separate to avoid muddying your PR, will rebase/undraft this PR once yours merges!

If you think it belongs there, then happy to push it. Up to you.

@bjohansebas

Copy link
Copy Markdown
Member

Hmm, I’m not sure. If you want, take a look at my PR. How about we give Ulises and the other reviewers a week to review it, then merge it and take a look at yours?

@bjohansebas

Copy link
Copy Markdown
Member

please rebase

@logaretm
logaretm force-pushed the awad/tracing-route-pattern branch from 4896d50 to 27974cb Compare October 22, 2026 15:29
@logaretm
logaretm marked this pull request as ready for review October 22, 2026 15:30
Layer instances are shared across requests, so reading a matched pattern
after asynchronous parameter processing can pick up another request's
pattern or lose it after a non-match. Nested routers can also leave their
pattern on handlers that resume in the outer route.

Let Layer.match optionally return the registered pattern while preserving
its existing boolean behavior. Capture the pattern on req before running
parameter callbacks, and restore the parent value alongside the other
router state when a nested router returns. Tracing then reads from one
request-local source instead of mutable state on a shared Layer.

Pattern capture and restoration use synchronous property access and the
existing restoration callback. Route.dispatch and handler signatures stay
unchanged, with no additional asynchronous context mechanism or per-layer
callback allocation.

Cover concurrent requests, nested router returns and errors, parameter
callbacks that invoke routers, and string, array, RegExp and empty patterns.

Validation: 768 tests passing, npm run lint, and npm run test-types.
@bjohansebas
bjohansebas force-pushed the awad/tracing-route-pattern branch from 882706f to 297875e Compare October 23, 2026 15:59
@bjohansebas

Copy link
Copy Markdown
Member

Okay, I made the change to keep the state isolated per request. Previously, the pattern was stored on Layer, which is shared across requests. If one request was waiting for an asynchronous parameter callback, another could overwrite that value and produce an incorrect trace.

Now:

  • Layer.match() returns the matched pattern.
  • We store it in req[matchedRoute] before running the parameter callbacks.
  • When exiting a nested router, we restore the parent router’s pattern.

The state is now isolated per request. Capturing and restoring it are synchronous

@bjohansebas
bjohansebas merged commit cee833e into pillarjs:master Oct 23, 2026
29 checks passed
@logaretm
logaretm deleted the awad/tracing-route-pattern branch October 23, 2026 16:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants