One of the things we noticed in PR https://github.com/elastic/kibana/pull/189041#issuecomment-2271983368, is that the current message Rule failed to execute because rule ran after it was disabled is kinda bogus. Especially given that PR, where we expect we may see more cases of rules that are disabled, but the tasks happened to be enabled (we want to silently, or maybe with a WARN or DEBUG) disable the task. There's now logic in TaskRunner to disable such tasks, but the place where we generate the error is returning a "run" result, where we really want to short-circuit this and not consider it a real error, or even rule run. The task happened to be enabled, but the rule says disabled, so it wins, and no need to be noisy about it, or mark the last execution result as a failure of this type.
So it looked like a little extra processing in some of the code flows would be required to make this happen, outside the referenced PR.
One of the things we noticed in PR https://github.com/elastic/kibana/pull/189041#issuecomment-2271983368, is that the current message
Rule failed to execute because rule ran after it was disabled
is kinda bogus. Especially given that PR, where we expect we may see more cases of rules that are disabled, but the tasks happened to be enabled (we want to silently, or maybe with a WARN or DEBUG) disable the task. There's now logic inTaskRunner
to disable such tasks, but the place where we generate the error is returning a "run" result, where we really want to short-circuit this and not consider it a real error, or even rule run. The task happened to be enabled, but the rule says disabled, so it wins, and no need to be noisy about it, or mark the last execution result as a failure of this type.So it looked like a little extra processing in some of the code flows would be required to make this happen, outside the referenced PR.