open-standards/wai/changes/2026-11-09-relay-and-quantum-service-answer-metrics.md
Transaction Science a5b1d10a39 wai-relay answers /metrics on its control listener, and wai-quantum-service on its API
The relay's operator's surface (the loopback listener and the Unix socket of its own user)
answers a connection that opens with an HTTP/1 request line as HTTP, once, after the same
check of its peer as every control request: GET /metrics (HEAD without the text) gives its
counters in the text exposition format through wai/wai-metrics: sessions open and opened,
tracks held and the downstream subscriptions across them, what its schedulers hold, objects in,
fetches by source, the door's refusals and drops, requests refused by why, upstream requests by
outcome, ratings held, going away, the unmetered energy marker, and the surface's own requests
by op and refusals by why. Another path, or a request through a front, is 404; another method
405. Every other connection keeps the JSON-lines protocol. Relay::fan_out gives the tracks and
subscriptions.

The quantum service answers GET /metrics in its outermost layer, before the API key and the
client's limits, outside its OpenAPI document and MCP endpoint: requests by route pattern,
method and status, jobs held by status, the memory running jobs hold, what the store held at
start, and the unmetered energy marker; through a front it is 404.

Each has a test that reads its answer strictly, moves its series with real sessions or a real
job, refuses each front field and finds no label value naming a party; the relay's socket test
holds a peer stated as another user to the refusal before /metrics is answered. The locks that
build the relay by path, and the service's, gain wai-metrics; the workflows that build either
run on a change to wai/wai-metrics.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
2026-11-09 20:06:07 -05:00

1.9 KiB

The relay and the quantum service answer GET /metrics

  • wai-relay answers GET /metrics on its control listener, the operator's surface (a TCP address on loopback, or a Unix socket of its own user), after the same check of its peer as every control request: a connection that opens with an HTTP/1 request line is answered as HTTP, once, and closed, and every other connection keeps the control surface's JSON lines. The counters, in the text exposition format (wai/wai-metrics): sessions open and opened, the tracks held and the downstream subscriptions across them (its fan-out), what its schedulers hold, the objects counted in, FETCHes and fills by where they came from, what the receipts door refused and dropped, requests refused by why, requests sent upstream by outcome, the rating claims held, whether it is going away, wai_relay_energy_unmetered (1 when no meter samples its own energy, so every record it signs carries the unmetered marker), and the control surface's own requests by op and refusals by why. HEAD is answered as GET without the text, another method 405, and another path or a request carrying a field a front sets 404.
  • wai-quantum-service answers GET /metrics before the API key and the client's limits, outside its OpenAPI document and its MCP endpoint: its requests by route, method and status (the route a path matched, never the path), the jobs it holds by status, the memory its running jobs hold, what its store held when it started, and wai_quantum_energy_unmetered. A request through a front is answered 404, as a path the service does not have.
  • No party is a label: every label value of either is fixed in its code, so no room, track, job, principal, token, key or address appears. Each one's test reads its answer strictly with wai-metrics' reader, moves its series with real sessions or a real job, and finds no label value that names a party.