Files
turnstone/tests
Patrick Buckley 80e7b9e9ca fix(mcp): review round 8 — push-success can't declare health, first-notify never debounced
- A single-kind push SUCCESS no longer clears the server error pill or
  stamps 'ok': _last_error / _last_refresh are server-scoped but a push
  refreshes only ONE kind, so a tools-failing server must not go green
  because its prompts push succeeded (a wrong-healthy window, bounded by
  the health tick — but a real 200-OK lie). Only a full pass declares
  'ok'; the failure's armed health-tick retry runs it. This reverts the
  over-reach of round 7's push-success outcome write (a self-inflicted
  regression) — net simpler.
- The (server, kind) debounce uses a None sentinel, not a 0.0 default:
  time.monotonic() counts from boot, so on a node whose process started
  < _NOTIFICATION_DEBOUNCE (5s) after boot, the 0.0 compare would debounce
  the VERY FIRST push — dropped with no recovery on the pool path. Absent
  stamp = never refreshed = always admit.
- _record_refresh_skipped completes the outcome-helper set: the three
  inline 'skipped' stamps now share one config-gated helper (with
  _record_refresh_success / _record_refresh_failure), and the
  reconnect-success branch routes through _record_refresh_success — no
  more hand-copied gates to drift.
- The per-message refreshers dict + on_debounce_drop closure are built
  ONCE per handler (both static and pool), not on every server->client
  message before the isinstance/debounce/coalesce early-returns.

Accepted (documented): an operator /mcp refresh that finds the connect
lock busy skips + arms the retry rather than waiting (waiting
re-introduces the refresh-budget exhaustion busy-skip exists to prevent).
4 findings refuted. Suite 9408 green.

Refs #839
2026-07-14 11:39:25 -07:00
..