Label request metrics by route, not by path (closes #254) #260

Merged
clawbot merged 8 commits from issue-254-metrics-route-pattern into next 2026-10-15 16:37:21 +02:00
8 Commits
Author SHA1 Message Date
sneak 547456f90e Keep the metrics entry at the top of Completed Steps
check / check (push) Waiting to run
Model: opus-5-5
2026-10-15 14:04:10 +00:00
sneak e5059086d7 Label a request with an empty path by the / route in metrics
When both r.URL.Path and r.URL.RawPath are empty, as for the request
line GET http://pixa.example HTTP/1.1, chi routes the request as /, but
routePattern asked Find about the empty path and labelled it unmatched.
It now uses / then, as chi does. After the rebase onto next, the TODO.md
entry is back at the top of Completed Steps.

Model: opus-5-5
2026-10-15 14:03:22 +00:00
sneak 09c55235c3 Test that metrics label a request with an empty path as /
A request line such as GET http://pixa.example HTTP/1.1 leaves the
request's path empty; chi routes it as /, so its label is the / route's
pattern.

Model: opus-5-5
2026-10-15 14:03:22 +00:00
sneak 2330ad8037 Keep the metrics entry at the top of Completed Steps
The rebase onto next placed the entry for this change below the one
next gained meanwhile; the TODO.md workflow puts a finished step at
the top.

Model: opus-5-5
2026-10-15 14:03:22 +00:00
sneak cdfca2fa03 Label requests for a subrouter's own path unmatched in metrics
For /v1 and /v1/, the path the image subrouter is mounted at, chi's
Find answers that path as the pattern without asking the subrouter,
which chi hands the request as / and which has no route there, so the
router answers 404. routePattern now asks the subrouter mounted there
whether it has a route for /, and labels the request "unmatched" when
it has none.

Model: opus-5-5
2026-10-15 14:03:22 +00:00
sneak 5f1436379b Test that metrics label requests for /v1 and /v1/ unmatched
No route answers /v1 or /v1/, the path the image subrouter is mounted
at, and the router answers both with 404, yet the metrics middleware
labels them "/v1" and "/v1/". The test now sends both and expects them
counted under "unmatched". It fails.

Model: opus-5-5
2026-10-15 14:03:22 +00:00
sneak f1127b7e32 Label request metrics by route, not by path (closes #254)
The metrics middleware gave the handler label each request's path, so
every new path added series that were never removed, and /metrics
listed encrypted URL tokens. The label is now the pattern of the chi
route the request matches, or "unmatched" for one that matches none.
The metrics library takes the label before calling the handler, so the
middleware asks the router with chi's Find which route matches.

Model: opus-5-5
2026-10-15 14:03:22 +00:00
sneak c49c7a3c3e Test that metrics label requests by route, not path
The new test sends two paths one route answers and three requests no
route answers through the metrics middleware, and expects the handler
label to hold the route's pattern and "unmatched". It fails: the label
is each request's path, so every new path adds series.

TestMetricsRecordsServedRequest serves its request outside any router,
so it now expects handler="unmatched" where it expected the path
handler="/test", as the owner approved in
#254 (comment).

Middleware gets a metricsRegistry field, nil being Prometheus' default
registry, so the new test can register with a registry of its own:
TestMetricsRecordsServedRequest registers with the default one.

Model: opus-5-5
2026-10-15 14:03:22 +00:00