docs(alarms): describe the real StreamAlarms open sequence, and close TST-16
The final integration review's non-blocker reservations, all documentation or comment truth except one test arm. The alarm feed opens provider_status -> snapshot_status -> cached active_alarm -> snapshot_complete, which is what GatewayAlarmMonitor has done since the snapshot_status frame landed. Two places still described the old order: docs/Grpc.md said provider_status arrived *after* the initial snapshot, contradicting its own snapshot_status section two paragraphs down, and AlarmFeedMessage's leading proto comment named neither status frame at all. Both now state the sequence the monitor emits, so a client author reading either one gets the frame order right. The proto comment change flows through the generated trees (Contracts, Go, Java) and the client descriptor set; the Rust vendored copy stays byte-identical to canonical. Python's generator does not carry proto comments into its output, so it has no delta. AlarmsHubPublisherTests' valueless-payload case covered snapshot_complete and provider_status but not snapshot_status, leaving the newest arm unpinned against the redaction switch that must ignore it. Added. WnWrapAlarmConsumer's ack comment led with the 2026-05-01 reading that -55 tracks the 8-arg overload, then refuted itself six lines later with the 2026-08-18 probe. It now leads with the observation labelled as narrower than it reads -- mirroring the correction already in docs/AlarmClientDiscovery.md -- so the block argues one thing: the 6-arg call site stays for parity, and rc semantics are per the probe. A paragraph orphaned by an earlier splice is rewrapped. Comment interior only; the file compiles on Windows. TST-16 gets a dated closure note rather than a rewrite: the flag it called dead was implemented 2026-08-18. GatewayDashboardDesign's /browse paragraph gains the failed-read carve-out GatewayConfiguration already documented, so the two agree that a failed read keeps its - placeholder.
This commit is contained in:
@@ -355,6 +355,8 @@ If TST-02's interim mitigation (flip retention off) is chosen instead of impleme
|
||||
|
||||
**Verification.** `dotnet build src/ZB.MOM.WW.MxGateway.Server`; test toggling the flag suppresses/shows values; docs match.
|
||||
|
||||
**Closed 2026-08-18 — implemented (the Design's recommended path).** The flag is no longer dead: it now gates value display on all three seams that carry a tag value. `Dashboard/DashboardLiveDataService.cs` substitutes `[redacted]` at the service boundary for each successfully read `/browse` tag (a failed read keeps its `-` placeholder, so the error row and the redaction cannot contradict each other); `Dashboard/Hubs/AlarmsHubPublisher.cs` clears `current_value`/`limit_value` from a **deep-cloned** `AlarmFeedMessage` before broadcasting to `/hubs/alarms`, and `DashboardEventBroadcaster` does the same for the events-hub mirror — clones, because the sources fan out to gRPC `StreamAlarms`/`StreamEvents` and the replay ring, so no gRPC client is affected by this dashboard-display flag. The flag is **kept**, default still `false`. The stale prose the Finding flagged is gone: `docs/GatewayConfiguration.md` and `docs/GatewayDashboardDesign.md` now describe the real behaviour. Status tracked in `00-tracking.md` (already **Done**).
|
||||
|
||||
---
|
||||
|
||||
## TST-17 — Vendor-gated alarm parity residuals silently lossy `Medium` · `—`
|
||||
|
||||
Reference in New Issue
Block a user