fix(telemetry): an outage is not a cache hit #545

Merged

coilyco-ops merged 1 commit from coilyco-ops/an-outage-is-not-a-cache-hit into main

2026-08-13 15:40:23 +00:00

AGit

coilyco-ops commented

2026-08-13 15:35:00 +00:00

Member

closes #540 closes #534 - a failed connect is a round trip that listed nothing, and reporting it as cached asserted the comfortable answer on the one turn it matters.

coilyco-ops added 1 commit

2026-08-13 15:35:01 +00:00

fix(telemetry): an outage is not a cache hit

ci / image-build (pull_request) Successful in 21s

Details

ci / test (pull_request) Successful in 35s

Details

ci / publish-echo-image (pull_request) Has been skipped

Details

ci / publish-observed (pull_request) Has been skipped

Details

39e357a35c

The attribute added an hour ago read cached as listed == 0, treating listed as
"went to the network". readyLocked returns false on a failed connect, which is
a round trip that failed. So a total MCP outage reported cached=true.

Worse, the attribute is set before the all-unavailable guard, which was
deliberate so it lands on a failing turn. Right instinct, wrong value: the
combination produces a confident wrong answer on exactly the turn someone is
reading the trace to understand.

Reaching the network and completing a listing are different things and one
counter cannot hold both. readyLocked now reports each:

  backing off      neither, no round trip is spent
  connect failed   reached, not listed
  cache fresh      neither
  listing failed   reached, not listed
  listing ok       both

So an outage reports cached=false, reached=1, listed=0, and the three together
say what happened.

Also adds mcp.tools.configured, the roster size, which closes sirens-echo#534.
With three servers and one listing, cached=false reads as "nothing was cached"
when two thirds was. The cached count is now derivable as configured - reached
without changing the type of an attribute that already shipped. That was QA's
own second option, and their reason for rejecting the first is the right one:
changing a just-landed attribute's type under its name is worse than the
ambiguity it fixes.

An empty roster now reports cached=false rather than true. Nothing was served
from cache because there is nothing to cache, and a profile with no tools
should not read as a hit. Neither issue named that case and I had it wrong too.

The tests go through Open against a dead port rather than asserting on the
counter, from QA's reproduction on 540. Same lesson as sirens-echo#413: a
budget can be correct while the send is not.

closes #540
closes #534

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: Kai Siren <coilysiren@gmail.com>
Co-authored-by: Claude <noreply@anthropic.com>