Provide indication to rule executor when rule is disabled/re-enabled

[nreese]

Geo containment rule caches containment boundaries between executions. #157934 requests that the boundaries cache be cleared when a rule is disabled/re-enabled. The problem is that the executor is not provided with any state to know when a rule is disabled or re-enabled.

The feature request is to provide the rule executor with state to indicate when a rule has been disabled or re-enabled. One suggested solution is to include enabledAt timestamp in rule state. Another suggestion would be a callback on rule disable. Personally, I like the callback on rule disablement.

[elasticmachine]

Pinging @elastic/response-ops (Team:ResponseOps)

[pmuellr]

This would have been a behavior change then, when we changed enable/disable to NOT delete it's task document, but mark it as "disabled" instead. The missing behavior is the clearing of rule and instance state. I think we clear instance state, actually (and recover alerts, etc).

I thought we had an issue open to add an explicit "clear rule state" action, to account for this. But not seeing one. Anyone else know of one?

I think that would be good idea as a general "fix it" tool, but would not be great as a UX, forcing the user to click some button "reset rule state" at times.

We have some issues open to coordinate calls to the rule type when lifecycle APIs are called, that seem more relevant:

• allow rules to "reset" themselves when params change #115544
• allow connector types to provide hooks/feedback during create/update/delete calls #106724

These all seem so related, we should look at them together when extending to this kind of functionality.

[ymao1]

Here's the issue for clearing task state: #140402

[ymao1]

Maybe we can set a flag on the rule type to clearStateOnDisable so a rule can choose to clear the state when the rule is disabled?

[pmuellr]

Or perhaps clearStateOnEnable - would someone be interested in the state, while it was disabled, so we'd just clear it when it's re-enabled. Would be good, diagnostic-wise anyway - perhaps confusing though.

The options I mentioned above for "lifecycle hooks for rule types" kinda thing is kinda over-bearing to solve this problem - expect everyone to implement a hook on disable (or enable) to clear task state. And it's not even clear what these "hooks" might allow - I think one issue pointed out a hook should be able to "veto" a creation / update; to "clear state", we'd probably need to provide some special function just for that (like replaceState() in the alert client). So ... having a rule-type option for "task state clearing on disable" seems like the easiest way to do this for rule implementors.