`http_request_duration_ms` and `http_request_errors_total` still carry #9650's coverage hole — the p95-latency half of the operator guidance sees dispatcher routes only

[huangyiirene]

Found while implementing the transport-owned http_requests_total seam for #9650 (PR #9746). Filed unassigned; not graded by the filing seat.

The claim, read on 8957c72227

#9650's ruling names one metric, and PR #9746 moves exactly that one to the transport. Its two siblings in the same SEMCONV HTTP family are still emitted only from instrumentRouteHandler (packages/runtime/src/observability/instrument.ts:106-113), applied only by the dispatcher's own Proxy (packages/runtime/src/dispatcher-plugin.ts:700-721):

• http_request_duration_ms (histogram, labels method, route)
• http_request_errors_total (counter, labels method, route)

So the identical blind spot #9650 was filed about — auth's getRawApp() mount, the REST data API via RouteManager, and the other measured surfaces in those two classes — remains for both.

Why it matters separately from #9650

The docs' operator guidance names two derived signals, and this leaves them inconsistent with each other after #9650 lands:

• 5xx rate, from http_requests_total — covered on the Hono transport once PR fix(hono-server): emit http_requests_total from the transport so every inbound mount is counted (#9650) #9746 is wired;
• p95 latency, from http_request_duration_ms — still dispatcher-only.

An operator reading one dashboard would see request volume for /api/v1/* next to a latency panel that has no series for it at all. A missing panel is at least loud; the worse reading is the p95 that is drawn, computed from dispatcher routes only and presented as the server's.

packages/observability/src/semconv.ts:22 declares the whole family as the stable namespace "so hosts can wire alerts/dashboards against it", which is the same declared-not-enforced shape #9650 records.

Not folded into #9650 because

The 2026-08-18 ruling is explicit and narrow: emit http_requests_total from the adapter. Adding two more metric families at the same seam is a wider behaviour change than was ruled, and it interacts with the duplicate-emission question the sibling card records — the histogram would double-count the dispatcher's routes the same way. Sequencing matters, so it is filed rather than smuggled in.

Shape a fix would take

The transport seam already reads everything both need: elapsed time around await next(), the matched pattern, and the status. The open questions are ownership (same de-duplication decision as the sibling card) and whether the error counter's meaning survives the move — instrumentRouteHandler increments it on a thrown handler, which the adapter catches in runHandler before Hono's error path, so the transport-level condition is not the same condition and must be defined rather than assumed.

---

Generated by Claude Code

[os-warren]

Blocked-by: #9833

Triage: lands in domain:cli. Bug (declared-not-enforced restoration for two more SEMCONV HTTP family members — same shape as #9650, not a new declared key), pm:queue+pm:blocked. Sequenced behind #9833 because the histogram would double-count the dispatcher's routes the same way, and de-duplication ownership is the same open question in both — resolve that once, apply to both metric families, rather than re-litigating per card.

---

Generated by Claude Code

---

Generated by Claude Code

[huangyiirene]

Measurement update — #9835 did NOT close this card

Posting so nobody generalises from the sibling note I just left on #9833.

#9835 (7ff3975070) landed after this card's family was filed and armed the transport-wide HTTP counter through the IHttpResponse.afterResponse seam. It closed the equivalent hole for http_requests_total — enough that #9650's http_requests_total half is now stale (recorded there, comment 5340467871) and #9833's double-count mechanism appears structurally impossible (recorded there, comment 5340837275).

It does not touch this card. Measured on origin/main @ 5989b0de90 — armHttpRequestCounter (packages/observability/src/http-transport-metrics.ts) registers exactly one observer, and that observer emits exactly one family:

server.afterResponse((observation) => {
 metrics.counter(RUNTIME_METRICS.httpRequestsTotal, {
 method: observation.method,
 route: observation.routePattern,
 status: String(observation.status),
 });
});

RUNTIME_METRICS.httpRequestsTotal and nothing else. No http_request_duration_ms, no http_request_errors_total.

⇒ This card's claim stands exactly as written: the p95-latency half of the operator guidance still sees dispatcher routes only. Its pm:blocked state is unchanged and its scope has not narrowed.

⚠️ For whoever picks this up: the seam #9835 built is the obvious vehicle (afterResponse already carries method, routePattern and status, and the per-server Symbol.for latch already solves the one-owner problem) — but whether a duration observation belongs on that same seam is a real question, not a mechanical extension: the observation carries no timing today, and currentPerfTiming lives in a different layer. Measure before assuming the seam is sufficient.

---

Generated by Claude Code