dohertj2/mxaccessgw
1
0
Fork 0
Code Issues 14 Pull Requests 2 Actions Packages Projects Releases Wiki Activity

feat(alarms): feed-level snapshot_status truncation frame on StreamAlarms

Browse Source
This commit is contained in:
Joseph Doherty
2026-08-17 07:16:51 -04:00
parent 094f2ffee4
commit fccf75324b
8 changed files with 920 additions and 197 deletions
Download Patch File Download Diff File Expand all files Collapse all files
gateway.md
+12 -1
View File
@@ -249,7 +249,18 @@ from broadcasting Clears for alarms it simply had no room to mention. That
suppression is reported structurally rather than only in a rate-limited worker
warning: the `QueryActiveAlarms` reply payload carries `snapshot_truncated`,
every `ActiveAlarmSnapshot` in it carries `from_truncated_snapshot`, and the
dashboard Alarms tab shows a warning banner while the flag is set. The flag
dashboard Alarms tab shows a warning banner while the flag is set. The live
`StreamAlarms` feed carries the same verdict at feed level as an
`AlarmSnapshotStatus` message (the `snapshot_status` oneof case), so a streaming
consumer learns it without polling `QueryActiveAlarms`. It is emitted on stream
open — after the `provider_status` frame and before the cached `active_alarm`
frames, so the caveat precedes the records it qualifies — and thereafter only on
a *change* of verdict (a status frame repeated every reconcile is one consumers
learn to ignore). The open-time frame is unconditional: an explicit
`truncated = false` is what separates a complete set from a gateway that never
sends the frame. A monitor restart drops the verdict with the cache generation it
describes, and because feed subscribers outlive the monitor's worker session that
drop is emitted as a clearing frame too. The flag
means "this active set may be incomplete", not "this record is unreliable" —
it is independent of the subtag-fallback `degraded` field above. It is not
latched: the first fetch that comes back under the cap is complete, restores