From 6cd91cc30a712b9a478dfcd6c130394af9abd34e Mon Sep 17 00:00:00 2001 From: Joseph Doherty Date: Fri, 31 Jul 2026 09:54:47 -0400 Subject: [PATCH] =?UTF-8?q?docs(alarms):=20record=20the=20#481=20live-gate?= =?UTF-8?q?=20finding=20=E2=80=94=20the=20comms-loss=20signal=20never=20fi?= =?UTF-8?q?res=20(#527)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The docker-dev gate for #481 could not close on its headline scenario, and the reason is worth recording next to the feature rather than only on the tracker: DriverInstanceActor.DisconnectObserved has no production sender, so a driver whose device dies mid-run is never detected. Filed as #527 with the live evidence (Modbus stayed Connected >10 min publishing Bad, and did not recover when its fixture returned until the node was restarted). What the gate DID establish: the change deploys and runs (scripted alarm materialised on central-1 against the seeded Modbus tag), and the #478 Layer 3 path does carry Bad into scripted input quality for Modbus, because that driver publishes Bad per tag rather than going silent. Claude-Session: https://claude.ai/code/session_015p7wGqy3YpZNCpDzTpGMKo --- docs/AlarmTracking.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/docs/AlarmTracking.md b/docs/AlarmTracking.md index f6560a28..2dd68cfd 100644 --- a/docs/AlarmTracking.md +++ b/docs/AlarmTracking.md @@ -183,6 +183,16 @@ Two things worth knowing before changing this: and is the correct reading of "this input's source is unreachable", but it is a behaviour change beyond scripted alarms. +⚠️ **The signal this hangs off does not currently fire for a mid-run device loss — see #527.** The #481 live +gate on docker-dev found that `DriverInstanceActor.DisconnectObserved` has **no production sender**: the only +paths into `Reconnecting` are a failed *initial* connect and an operator Force Reconnect. A Modbus driver +whose fixture was stopped stayed `Connected` for >10 minutes publishing per-tag Bad, and did not recover when +the fixture came back until the node was restarted. So the fan-out above — and the native `#477` Layer 2 +annotation it mirrors — are correctly wired to a signal that a dying device never raises. What partially +covers the gap today is that Modbus publishes Bad *per tag* rather than going silent, so #478 Layer 3 does +carry Bad into scripted input quality for that driver; that is a per-driver accident, not a guarantee, and it +does nothing for native conditions or for recovery. Closing #527 is what makes this path reachable. + **Cold start vs. a driver reporting Bad (#478 Finding 3, closed by #481).** `WorstInputStatus` used to skip every input whose *value* was null as "no data yet". A comms-lost driver produces exactly that shape — Bad with no value — so the skip was hiding the case that matters most. The upstream source now stamps a