Context
PR #274 added per-entity debounce thresholds. When multiple entities with different resolved configs report the same fault_code, the last reporter's config determines the status transition. This is documented behavior but can be a production footgun.
Example
Motor (confirmation_threshold=-5) reports OVERHEAT -> counter=-1, PREFAILED.
Lidar (confirmation_threshold=-1) reports same OVERHEAT -> counter=-2, lidar config applied, -2<=-1 -> CONFIRMED.
Motor's debounce policy was bypassed because lidar came in with a more lenient config.
Proposed solution
Add RCLCPP_WARN_ONCE (or RCLCPP_WARN_THROTTLE) when a fault_code receives events with different resolved DebounceConfig values. This requires tracking per-fault the last-used config (e.g., a std::unordered_map<std::string, DebounceConfig> in FaultManagerNode).
Alternative: validate at YAML load time whether configured prefixes could cause overlapping matches for common fault_code patterns.
Why not done in #274
Requires per-fault state tracking in the node layer purely for a diagnostic warning. Decided to keep the initial implementation simple and track this separately.
Context
PR #274 added per-entity debounce thresholds. When multiple entities with different resolved configs report the same
fault_code, the last reporter's config determines the status transition. This is documented behavior but can be a production footgun.Example
Motor (
confirmation_threshold=-5) reportsOVERHEAT-> counter=-1, PREFAILED.Lidar (
confirmation_threshold=-1) reports sameOVERHEAT-> counter=-2, lidar config applied, -2<=-1 -> CONFIRMED.Motor's debounce policy was bypassed because lidar came in with a more lenient config.
Proposed solution
Add
RCLCPP_WARN_ONCE(orRCLCPP_WARN_THROTTLE) when afault_codereceives events with different resolvedDebounceConfigvalues. This requires tracking per-fault the last-used config (e.g., astd::unordered_map<std::string, DebounceConfig>inFaultManagerNode).Alternative: validate at YAML load time whether configured prefixes could cause overlapping matches for common fault_code patterns.
Why not done in #274
Requires per-fault state tracking in the node layer purely for a diagnostic warning. Decided to keep the initial implementation simple and track this separately.