You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Items 1 (canary partial-output timeout), 2 (vLLM message wording), 3 (preference-list reconciliation — teardown on deselection, never on reordering), 5 (steward cancel-by-id, including the registration-order and mid-dispatch races found in #833's own review), and 6 (candidate servability, including backend truth: parserless vllm-only cards rejected pre-placement, and multi-engine cards whose stamped backend resolves to vllm rejected post-placement) are implemented with focused tests on feature/steward-hardening (#833).
Canary state is visible only on the hosting API node._steward_canary is process-local, so during a failure window the hosting API reports degraded while every other API reports ready. Self-heals once the third failure tears the instance down, but the pre-repair window is node-dependent. Needs cluster-visible propagation or forwarding status reads to the prober — wire-adjacent, wants its own design pass.
Cancel during tool execution waits for the tool to finish. (From Steward hardening: canary truth, cancel-by-id, placement servability #833 review, severity 2.) cancel_turn arriving while _run_investigation awaits execute_tool latches the turn but cannot interrupt the running tool; the response stays open until that bounded read-only call returns, then ends at the next latch check. The turn does terminate and every steward tool is a bounded read, so the residual is added latency on one tool call (worst case a doctor run, seconds). A true interrupt needs a cancel scope/event around tool execution — plumbing a cross-task CancelScope through an async generator is exactly the anyio pattern that breeds subtle bugs, so it deserves its own careful change rather than riding a hardening batch.
Review triage on #829 (severity rubric in CLAUDE.md) confirmed real but sub-High findings, deferred here rather than churning the merge PR.
Status: PR #833 addresses items 1, 2, 3, 5, and 6
Items 1 (canary partial-output timeout), 2 (vLLM message wording), 3 (preference-list reconciliation — teardown on deselection, never on reordering), 5 (steward cancel-by-id, including the registration-order and mid-dispatch races found in #833's own review), and 6 (candidate servability, including backend truth: parserless vllm-only cards rejected pre-placement, and multi-engine cards whose stamped backend resolves to vllm rejected post-placement) are implemented with focused tests on
feature/steward-hardening(#833).Remaining after #833
Canary state is visible only on the hosting API node.
_steward_canaryis process-local, so during a failure window the hosting API reportsdegradedwhile every other API reportsready. Self-heals once the third failure tears the instance down, but the pre-repair window is node-dependent. Needs cluster-visible propagation or forwarding status reads to the prober — wire-adjacent, wants its own design pass.Cancel during tool execution waits for the tool to finish. (From Steward hardening: canary truth, cancel-by-id, placement servability #833 review, severity 2.)
cancel_turnarriving while_run_investigationawaitsexecute_toollatches the turn but cannot interrupt the running tool; the response stays open until that bounded read-only call returns, then ends at the next latch check. The turn does terminate and every steward tool is a bounded read, so the residual is added latency on one tool call (worst case a doctor run, seconds). A true interrupt needs a cancel scope/event around tool execution — plumbing a cross-task CancelScope through an async generator is exactly the anyio pattern that breeds subtle bugs, so it deserves its own careful change rather than riding a hardening batch.