Problem
Fault-remediation currently routes events to remediation actions purely by recommendedAction string. There's no mechanism to filter events based on other HealthEvent fields like errorCode, agent, or checkName.
This means if multiple sources generate events with the same recommendedAction (e.g., CONTACT_SUPPORT), there's no way to selectively remediate only a subset of them. All events with that action will trigger remediation, or none will.
Without filtering, operators are forced to either:
- Remediate all events for a given action regardless of source (noisy, potentially incorrect)
- Not configure that action at all (blocks legitimate use cases)
Proposed Solution: Drop Rules
Add a global, CEL-based event filter at the fault-remediation entry point. Drop rules are evaluated in handleRemediationEvent() before action selection — if any rule matches, the event is silently dropped (marked as processed, no side effects).
Config
# Only remediate CONTACT_SUPPORT events with a specific errorCode
[[dropRules]]
expression = "event.recommendedAction == 5.0 && !('MANUAL_SUPPORT_REQUEST' in event.errorCode)"Rules use the same CEL environment as fault-quarantine (event.* variables, ext.Strings()), so operators familiar with FQ rule expressions can write drop rules without learning a new syntax.
Problem
Fault-remediation currently routes events to remediation actions purely by
recommendedActionstring. There's no mechanism to filter events based on other HealthEvent fields likeerrorCode,agent, orcheckName.This means if multiple sources generate events with the same
recommendedAction(e.g.,CONTACT_SUPPORT), there's no way to selectively remediate only a subset of them. All events with that action will trigger remediation, or none will.Without filtering, operators are forced to either:
Proposed Solution: Drop Rules
Add a global, CEL-based event filter at the fault-remediation entry point. Drop rules are evaluated in
handleRemediationEvent()before action selection — if any rule matches, the event is silently dropped (marked as processed, no side effects).Config
Rules use the same CEL environment as fault-quarantine (
event.*variables,ext.Strings()), so operators familiar with FQ rule expressions can write drop rules without learning a new syntax.