fix(dashboard): alarms feed doc row + monitor-contract comment + mid-truncation attach test

The In-process page feeds table still described the alarms page's subscription as
provider status only, contradicting the three passages updated in 7b6dfba.

The loop's catch-all comment (and the cadence bullet that repeated it) claimed the
monitor completes a subscriber's stream on restart. It does not: ClearCache pushes
snapshot_status(false) through the still-open channel, and a subscriber is only
completed-with-error on a failed TryWrite, or removed by its own disposal.

The SnapshotStatus arm's priming claim had no test behind it — every push test
attached to an untruncated feed and pushed the edge itself. ScriptedAlarmFeed now
replays an optional open sequence, and a new test attaches to a feed already
primed provider_status then snapshot_status(truncated) and asserts the banner
comes up with no edge pushed after render.
This commit is contained in:
Joseph Doherty
2026-08-18 06:49:20 -04:00
parent d3ac52758c
commit f57a6ae5ff
3 changed files with 63 additions and 8 deletions
@@ -258,10 +258,13 @@
}
catch
{
// The monitor completes a subscriber's stream when it falls behind, and
// again when the monitor restarts. Both are recoverable by resubscribing;
// the badge and banner hold their last values in the meantime, and the
// resubscribe is primed with the current ones.
// The monitor drops a subscriber whose queue it cannot write to, completing
// that stream with an error; short of cancellation or disposal that is the
// only way this enumeration ends. A monitor restart is NOT one of them — it
// keeps the channel and pushes the cleared status frames through it — so this
// catch is the fell-behind case, recoverable by resubscribing. The badge and
// banner hold their last values meanwhile, and the resubscribe is primed with
// the current ones.
}
try