fix: keep the route template, not the concrete path, on server spans - #17
Merged
Conversation
url.path is the concrete request target, so on a content route it carried the customer's own file path - the same data the memory-mcp body redaction already protects. When the instrumentation matched a route we now keep the template instead: same grouping value, no user data. url.full repeats the path, so it goes with it. Only when a route matched. An unmatched path (scanner probes, static assets) is not user content and stays verbatim - that is what makes a routing regression visible. Also un-mangles express RegExp routes, which reached OTel as the regex source: /v1/^\/memories\/([^/]+)\/notes\/(.+)$/ -> /v1/memories/:param/notes/:path. Those were unreadable in a trace list and useless as a facet.
vreshch
force-pushed
the
fix/redact-request-paths
branch
from
August 9, 2026 14:23
25239a1 to
0dee820
Compare
Merged
vreshch
added a commit
that referenced
this pull request
Aug 9, 2026
Ships the request-path redaction from #17: on a matched route the span carries the route template, not the customer's concrete file path. README documents the behaviour under 'What gets traced'. Also exports readableRoute, which un-mangles express RegExp routes from their regex source.
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
1 participant
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.
Companion to agentage/web#473, which stops
mcp.tool.argscarrying customer file paths. The REST surface leaks the same data throughurl.path, which is by definition the concrete request target:The body is redacted upstream; the title telling you what the note is about was not.
The fix
When the instrumentation matched a route, keep the template on
url.pathinstead of the concrete path. Same grouping value, no user data.url.fullrepeats the path, so it goes with it - the host stays inserver.address.Only when a route matched. An unmatched path (scanner probes, static assets -
/files/index.php,/badge/agents-8%20+%20AGENTS.md) is not user content and stays verbatim; that is what makes a routing regression visible. Client spans are untouched.Bonus: routes stop being unreadable
Express routes registered as a
RegExpreach OTel as the regex source.readableRouteturns them back:Those were unusable as a facet in SigNoz and cryptic in a trace list, so this is worth having on its own.
Verified
npm run verifygreen, 51/51 across 9 filesurl.fullremoval, an assertion that no fragment of a title survives, unmatched paths left alone, client spans left alone, and both RegExp route shapesRollout
Kit change, so it reaches production only as services pick up the new version. Suggest releasing and bumping
web(memory-mcp, backend, sync) first - that is where the content routes live; landing/catalog/dashboard/admin get the readable-route improvement whenever they next bump.