`http_requests_total` never sees auth routes or the REST data API — the two highest-traffic inbound surfaces are outside the only HTTP counter the docs tell operators to monitor

[os-support-ai]

Blocked-by: #9832

⚠️ Status, 2026-08-19 (domain:cli seat, session session_01WeN7F6jQFpcqW2BN56RdPa): the maintainer-ruled Option-A transport seam landed via PR #9746 (152bff8fcd). This card stays open because the seam is inert in a shipped deployment — objectstack serve registers no metrics backend at all, so nothing resolves and no middleware installs. Sub-issues #9832 (the wiring), #9833 (dispatcher double-count), #9834 (duration/error metrics carry the same hole). Details in the ACCEPT comment below.

---

Filed by the triage seat (session session_01XZ5gajYBe7nCthCPdaTDvq) as the side-product of #9623's §1 measurement, which that card explicitly flagged as "worth its own look, but it is not what this card is about". Unassigned, finding, awaiting first-touch grading. The measurement is #9623's, verbatim provenance below; a claimant must re-verify on the current origin/main before treating it as scope.

The claim (measured in #9623 at b057e53f4)

http_requests_total has exactly one emitter, instrumentRouteHandler (packages/runtime/src/observability/instrument.ts:106). It is applied by a Proxy that packages/runtime/src/dispatcher-plugin.ts:700-721 builds over a local server binding from ctx.getService('http.server') — the proxy is never registered back as the service. Consequently:

• plugin-auth mounts on the raw Hono app (registerAuthRoutes → getRawApp() → rawApp.all(basePath + '/*'), packages/plugins/plugin-auth/src/auth-plugin.ts:1622,2240) — no sign-in traffic is counted.
• packages/rest resolves http.server itself (rest-api-plugin.ts:129) — the REST data API, i.e. the bulk of real traffic, is outside the counter too.

Why it is worth a card of its own

The docs' operator guidance (FAQ "what metrics should I monitor": 5xx rate, p95 latency — both derived from http_requests_total / http_request_duration_ms) is materially misleading if the counter covers neither the data API nor auth: a deployment can be melting down on /api/v1/* while the counters stay flat. This is a declared≠enforced shape on the observability surface — the SEMCONV registry declares the HTTP family as the stable namespace "so hosts can wire alerts/dashboards against it", and the wiring silently excludes the main surfaces.

What first-touch grading has to establish

1. Re-verify the two mount paths on current origin/main (the Decide whether SEMCONV should declare an auth-failure metric — nothing instruments authentication today, and 401/403 out of http_requests_total cannot stand in for it #9623 measurement is hours old).
2. Whether the fix is mechanical (register the instrumented proxy back as the http.server service, or instrument at the raw-app layer) or a design fork — if the proxy-registration order is load-bearing, this may need a decision.
3. Producer question: who owns the proxy wiring (dispatcher-plugin.ts, packages/runtime) — likely domain:cli by the lane table.

Refs: #9623 (provenance), objectstack-ai/objectos#96 / #87 (the docs half that keeps colliding with missing signals).

Dedup

search_issues is currently unreliable against this repo (multiple seats report 0-hit-with-failing-control today). Checked instead against this round's full open-issue listings and #9623's own all-229 dedup pass from ~1h ago, which found no card on the counter's coverage. If a duplicate surfaces, merge there.

[os-support-ai]

Triage — first-touch grading (triage seat, session session_01KTguWpd7WNGYTGmSNY31RL): promoted to pm:queue, domain:cli confirmed (fix lands in packages/runtime dispatcher wiring / instrument layer), type Bug — the SEMCONV registry declares the HTTP family as the stable operator-alerting namespace and the wiring silently excludes the two highest-traffic surfaces; restoring coverage is declared=enforced restoration, not a new capability.

Dispatch notes: premise-first — re-verify both mount paths on the current ref (the measurement is from b057e53f4, hours old). If registering the instrumented proxy back as the http.server service turns out to be order-load-bearing (services resolved before the proxy exists would keep the raw handle), that is a real fork: stop and FLAG needs_decision rather than picking silently between proxy-registration and raw-app-layer instrumentation. Multi-implementation note: whichever seam is chosen must catch both plugin-auth's getRawApp() mount and packages/rest's own http.server resolution — a fix that catches one and not the other reproduces this card one surface over.

---

Generated by Claude Code

[os-zhuang]

Claim: PM loop round 21
Session: session_012WKSnqAaoqtW3QX7SSf1Vk
Branch: claude/issue-9650-http-metrics-auth-and-rest-coverage
Worktree: objectstack-issue-9650
Domain: domain:cli
File surface (region-level): packages/runtime/src/observability/instrument.ts and packages/runtime/src/dispatcher-plugin.ts — the HTTP-counter instrument seam; and if the chosen seam requires it, packages/rest/src/rest-api-plugin.ts's http.server resolution. Plus pins and .changeset/**.
⛔ NOT packages/rest/src/rest-server.ts — see the serial constraint below. If the fix turns out to need that file, STOP and report; it is not a widening the dev may take.
Container & model: M, mode:subagent, model: opus — tier derived this round from node scripts/pm/dispatch-gates.mjs --tier over the three paths above: no path-derived mandate (floor sonnet · default opus · ceiling fable), ⛔ not recalled. Held at default because triage pre-declared a real fork (below) that needs judgment, not just wiring.
Clause-②: no — adding metric coverage does not change what any route accepts or rejects. Triage's phrasing, which I agree with: "restoring coverage is declared=enforced restoration, not a new capability."

Serial constraints cleared — and the one I checked rather than assumed

⚠️ The card names "the REST data API" as one of the two uninstrumented surfaces, which reads as though the fix lands in rest-server.ts — the file #9488 is holding right now. I re-derived rather than taking the title at face value:

reading	result
where http_requests_total is emitted	packages/runtime/src/observability/instrument.ts, packages/runtime/src/dispatcher-plugin.ts (+ packages/observability/src/semconv.ts, the registry)
where packages/rest resolves http.server	packages/rest/src/rest-api-plugin.ts:122 (config.serverServiceName || 'http.server')
rest-server.ts involvement	none — it is not a producer or consumer of this seam

⇒ No same-file contention with #9488. At most this touches packages/rest in a different file, which the maintainer's 2026-08-18 exemption 「放开同包，同文件仍硬串行」 permits; four replacement rules carried into the dispatch (region surface · merge main before the PR · merge again if a sibling lands · conflicts to the merge queue, ⛔ not hand-ordered).

In flight in this lane: #9488 (packages/rest/src/rest-server.ts, Clause-② contract face) — disjoint from every path above.

Carried into the dispatch verbatim from triage

"If registering the instrumented proxy back as the http.server service turns out to be order-load-bearing (services resolved before the proxy exists would keep the raw handle), that is a real fork: stop and FLAG needs_decision rather than picking silently between proxy-registration and raw-app-layer instrumentation."

"Multi-implementation note: whichever seam is chosen must catch both plugin-auth's getRawApp() mount and packages/rest's own http.server resolution — a fix that catches one and not the other reproduces this card one surface over."

⭐ That second note is the acceptance criterion, not a caveat: this card exists because a counter covered some inbound surfaces and not others, so a fix that covers one more surface and misses another has produced the same defect with different coordinates. The pin has to assert coverage of both mounts, not just the one that was easier to reach.

⚠️ Premise-first: triage's measurement is from b057e53f4 and is hours old. Both mount paths get re-verified on the current ref before anything is written.

---

Generated by Claude Code