docs(alarms): record the #481 live-gate finding — the comms-loss signal never fires (#527)

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
This commit is contained in:
Joseph Doherty
2026-07-31 09:54:47 -04:00
parent c81cef39f5
commit 6cd91cc30a
+10
View File
@@ -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