test(galaxy): #872 pin the detected_by rule per source
v2-ci / unit-tests (push) Has been cancelled
v2-ci / unit-tests (push) Has been cancelled
The rule fix itself landed in 1a08b4f7 (detail-0 failure rows route on
category); its test only exercised raw_detected_by = 3. Add per-source
coverage for every MxStatusSource value mxaccessgw's MapSource emits
(-1, 0..5, and an out-of-range value) across the failure categories, plus
the live-captured shape the old rule got wrong (OperationalError detected
by the responding automation object, mxaccessgw docs/AlarmProbeFindings.md)
and a RequestingLmx CommunicationError positive control. All 10 new cases
fail against the old 'detail 0 && raw_detected_by != 0 => comms' rule.
Comment in FromMxStatus now cites MapSource and says why NMX (2/3) is not
a transport signal. Item 1 (Warning/Pending) stays open pending a capture.
Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
@@ -133,6 +133,9 @@ internal static class StatusCodeMap
|
||||
// the belief that a non-zero source meant a pre-MXAccess transport failure — but every detected_by value
|
||||
// names an MXAccess layer (0 requesting LMX, 1 responding LMX, 2/3 NMX, 4/5 automation object; the
|
||||
// gateway's own failures arrive as ProtocolStatus, never as a status row), so the category decides (#872).
|
||||
// The numbering is mxaccessgw's MxStatusProxyConverter.MapSource; NMX (2/3) names the inter-node message
|
||||
// layer that noticed the failure, not a transport fault — a real comms loss is category CommunicationError
|
||||
// or detail 2/5, which FromCategory already maps to BadCommunicationError.
|
||||
return FromCategory(status, logger);
|
||||
}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user