* Move isMlRule helper to a more general location
And use it during rule execution as well.
* Add error message back to rule error status
This was unintentionally removed in a previous merge commit.
* Expose mlClient as part of ML's Setup contract
This allows dependent plugins to leverage the exposed services without
having to define their own ml paths, e.g. "ml.jobs"
* Move ML Job predicates to common folder
These are pure functions and used on both the client and server.
* WIP: Check ML Job status on ML Rule execution
This works, but unfortunately it pushes this executor function to a
complexity of 25. We're gonna refactor this next.
* Move isMlRule and RuleType to common
These are used on both the frontend and the backend, and can be shared.
* Refactor Signal Rule executor to use RuleStatusService
RuleStatusService holds the logic for updating the current status as
well as adding an error status. It leverages a simple
RuleStatusSavedObjectClient to handle the communication with
SavedObjects.
This removes the need for our specialized 'writeError', 'writeGap', and
'writeSuccess' functions, which duplicated much of the rule status
logic and code. It also fixes a bug with gap failures, with should have
been treated the same as other failures.
NB that an error does not necessarily prevent the rule from running, as
in the case of a gap or an ML Job not running.
This also adds a buildRuleMessage helper to reduce the noise of
generating logs/messages, and to make them more consistent.
* Remove unneeded 'async' keywords
We're not awaiting here, so we can just return the promise.
* Make buildRuleStatusAttributes synchronous
We weren't doing anything async here, and in fact the returning of a
promise was causing a bug when we tried to spread it into our attributes
object.
* Fix incorrectly-named RuleStatus attributes
This mapping could be done within the ruleStatusService, but it
lives outside it for now.
Also renames the object holding these values to the more general
'result,' as creationSuccess implies it always succeeds.
* Move our rule message helpers to a separate file
Adds some tests, as well.
* Refactor how rule status objects interact
Only ruleStatusSavedObjectsClient receives a savedObjectsClient, the
other functions receive the ruleStatusSavedObjectsClient
* pluralizes savedObjects in ruleStatusSavedObjectsClient
* Backfills tests
* Handle adding multiple errors during a single rule execution
We were storing state in our RuleStatusClient, and consequently could
get into a situation where that state did not reflect reality, and we
would incorrectly try to delete a SavedObject that had already been
deleted.
Rather than try to store the _correct_ state in the service, we remove
state entirely and just fetch our statuses on each action.
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
8b31ce0a89