Extended AlarmClientWmProbeTests.ProbeAlarmClientWmMessages to also
call GetStatistics every ~2s during the pump window. Re-ran on the
dev rig 2026-05-01:
- GetStatistics is safely callable from the same thread that did
RegisterConsumer + Subscribe. Every poll (9 calls / 20s window)
returned rc=0, no exceptions.
- Galaxy currently has zero active alarms. total=0 active=0
suppressed=0 newAlarms=0 across every poll. positions[] and
handles[] arrays were empty.
- changes=1 codes=[7] was constant across all polls, matching the
constant 1 Hz WM 0xC275 cadence — same heartbeat semantics
exposed through both the WM path and the pull API.
Confirms the polling design is mechanically viable: GetStatistics
threading-affinity is fine and the call is cheap. The remaining
unknown is whether GetStatistics populates positions[] / handles[]
with real entries when an alarm actually fires. Proving that
requires triggering an alarm — next probe is an MxAccess write to a
$Alarm-extended boolean tag (reference pending).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Joseph Doherty
3ff4969224