Native alarm conditions stay inactive after a rebuild when the alarm-tag set is unchanged #641
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
A full address-space rebuild recreates native alarm conditions inactive.
The host does not re-subscribe alarms when the subscribed alarm set is unchanged.
Result: an active native alarm (any source) shows inactive until its next transition.
Found during MTConnect CONDITION work (#626).
Landed on master (merge
5af9aae2, ddd76782..bd23f557): native alarm conditions are carried across a rebuild when the alarm-tag set is unchanged, so they no longer stay inactive; unclaimed captures are discarded. Verified: unit suites + live docker-dev gate: UNS-reference deploy rebuild=True 'carried 2', Xtravel stays Active sev800 with original timestamp. Related split-off: #647 (FOCAS native alarms unroutable). Closing.