[ResponseOps]: Refactor alerting task runner - combine loadRuleAttributesAndRun() and validateAndExecuteRule() #132079

pmuellr · 2022-05-11T21:12:26Z

Summary

Extract the loadRuleAttributesAndRun() and validateAndExecuteRule() methods from the alerting task manager, into a separate module.

Also adds a new RuleExecutionStatusErrorReasons - validate. Previously, validation errors ended up with an unknown reason, now validation is a first class error reason.

meta issue: #124206

Checklist

Delete any items that are not applicable to this PR.

Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
Unit or functional tests were updated or added to match the most common scenarios

…tributesAndRun() and validateAndExecuteRule() resolves elastic#131544 Extract the `loadRuleAttributesAndRun()` and `validateAndExecuteRule()` methods from the alerting task manager, into a separate module. meta issue: elastic#124206

pmuellr · 2022-06-02T16:19:37Z

x-pack/plugins/alerting/server/task_runner/rule_loader.ts

+  try {
+    validatedParams = validateRuleTypeParams<Params>(rule.params, paramValidator);
+  } catch (err) {
+    throw new ErrorWithReason(RuleExecutionStatusErrorReasons.Validate, err);


The code in task_runner this was abstracted from didn't catch a validation exception, and previously ended up with a reason of Unknown set back in task runner. Now, it's an explicit reason.

pmuellr · 2022-06-02T16:21:08Z

x-pack/test/alerting_api_integration/spaces_only/tests/alerting/execution_status.ts

@@ -183,7 +183,7 @@ export default function executionStatusAlertTests({ getService }: FtrProviderCon
      await ensureAlertUpdatedAtHasNotChanged(alertId, alertUpdatedAt);
    });

-    it('should eventually have error reason "unknown" when appropriate', async () => {
+    it('should eventually have error reason "validate" when appropriate', async () => {


As mentioned ^^^, previously validation errors returned a reason of unknown, but now return the new reason. I didn't see an obvious way to test the unknown status anymore, which I guess is kinda good!

pmuellr · 2022-06-02T16:22:20Z

x-pack/plugins/triggers_actions_ui/public/application/sections/rules_list/translations.ts

@@ -136,6 +143,7 @@ export const rulesErrorReasonTranslationsMapping = {
  license: ALERT_ERROR_LICENSE_REASON,
  timeout: ALERT_ERROR_TIMEOUT_REASON,
  disabled: ALERT_ERROR_DISABLED_REASON,
+  validate: ALERT_ERROR_VALIDATE_REASON,


The way the reason type is defined, this code generated an error until I added this new reason. Quite nice - I knew I'd have to do something in the UX, wasn't sure where, and didn't have to go hunting for it, just run the type checker!

elasticmachine · 2022-06-02T16:22:59Z

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

ymao1 · 2022-06-02T18:04:43Z

x-pack/plugins/alerting/server/task_runner/task_runner.ts

@@ -599,12 +549,12 @@ export class TaskRunner<
      params: { alertId: ruleId, spaceId },
    } = this.taskInstance;
    try {
-      const decryptedAttributes = await this.getDecryptedAttributes(ruleId, spaceId);
+      const decryptedAttributes = await getDecryptedAttributes(this.context, ruleId, spaceId);


Do we need to get a new fake request and rules client again here? Could we pass the rules client we get back from loadRule and use it here?

Heh, ya. Good catch - we should have caught that when the method was originally added, but who would have caught it in this maze‽‽‽. We only need fakeRequest to create the rulesClient, so was able to cut out a bit more ...

I've had to now use PublicMethodsOf<RulesClient> numerous times now, so going to create an alias of that as well named RulesClientApi.

code in commit 24da47b

ymao1 · 2022-06-02T18:11:30Z

x-pack/plugins/alerting/server/task_runner/rule_loader.test.ts

+    jest.restoreAllMocks();
+  });
+
+  describe('loadRule()', () => {


Do you think we could remove some of the tests inside task_runner.test.ts that test for errors when loading the rule since we have these tests here? I think as long as we have test coverage for what happens in the event of these various failures and then one test inside the task runner test for what happens when loadRule throws an error, we should be covered right?

I'm not real comfortable with that, though it would be a nice goal. The error tests I saw were also checking some other side effects of the error processing, so we'd be missing those tests.

Were there some specific tests you were thinking of? Maybe I missed some obvious ones we could remove ...

Just quickly looking at the tests, I was thinking:

validates params before running the rule type

uses API key when provided

doesn't use API key when not provided

recovers gracefully when the Alert Task Runner throws an exception when fetching the encrypted attributes

recovers gracefully when the Alert Task Runner throws an exception when license is higher than supported

recovers gracefully when the Alert Task Runner throws an exception when getting internal Services

recovers gracefully when the Alert Task Runner throws an exception when fetching attributes

successfully bails on execution if the rule is disabled

These all seem to test things inside the rule loading? But if you're not comfortable with it, we can save it for a later time.

Looking at validates params before running the rule type, it's testing the result of taskRunner.run(), so we'd lose the test of that. I'm not sure how critical that is, and we'd have to hunt down if we are testing all these in another way. Some of the other tests are checking the usageCounter and eventLog - again, not sure.

My current thought is that once we've boiled this module down a bit more, we'll probably see some streamlining we can do, including with the tests. So feels like not the best time to be doing this.

I can open an issue to track, we could add it to the task runner meta issue ...

That sounds good!

created #133831 to track and added to the meta issue #124206

ymao1

LGTM!

pmuellr · 2022-06-07T19:53:59Z

@elasticmachine merge upstream

kibana-ci · 2022-06-07T20:57:52Z

💚 Build Succeeded

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
`triggersActionsUi`	810.8KB	811.0KB	+174.0B

Public APIs missing exports

Total count of every type that is part of your API that should be exported but is not. This will cause broken links in the API documentation system. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats exports for more detailed information.

id	before	after	diff
`alerting`	19	20	+1

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
`alerting`	38.4KB	38.4KB	+22.0B

History

💚 Build #49182 succeeded 24da47b
💚 Build #48876 succeeded a152bfd
💚 Build #47931 succeeded 4de3842
💔 Build #47742 failed 25a3ab2
💚 Build #47468 succeeded 39fb0b5
💔 Build #46655 failed fb08956

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

ersin-erdal · 2022-06-08T12:12:03Z

x-pack/plugins/alerting/server/task_runner/task_runner.ts

@@ -567,17 +521,17 @@ export class TaskRunner<
    };
  }

-  private async validateAndExecuteRule(
+  private async prepareAndExecuteRule(


Cant we just move getExecutionHandler into executeRule and get rid of this prepareAndExecuteRule function?

seems possible; let me give it a go ...

seemed to work fine - this was done in commit 5d00b9c

pmuellr · 2022-06-13T14:38:08Z

@elasticmachine merge upstream

pmuellr · 2022-06-14T20:09:53Z

@elasticmachine merge upstream

kibana-ci · 2022-06-14T21:15:00Z

💚 Build Succeeded

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
`triggersActionsUi`	831.7KB	831.9KB	+174.0B

Public APIs missing exports

Total count of every type that is part of your API that should be exported but is not. This will cause broken links in the API documentation system. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats exports for more detailed information.

id	before	after	diff
`alerting`	19	20	+1

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
`alerting`	38.4KB	38.4KB	+22.0B

History

💚 Build #50568 succeeded 5d00b9c
💔 Build #50522 failed 25a484f
💚 Build #49713 succeeded 4948970
💚 Build #49182 succeeded 24da47b
💚 Build #48876 succeeded a152bfd
💚 Build #47931 succeeded 4de3842

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

pmuellr force-pushed the alerting/refactor-tr-131544 branch 4 times, most recently from 67b868f to ee073ca Compare May 19, 2022 19:05

pmuellr force-pushed the alerting/refactor-tr-131544 branch 2 times, most recently from 25a3ab2 to 4de3842 Compare May 26, 2022 19:49

pmuellr force-pushed the alerting/refactor-tr-131544 branch from 4de3842 to a152bfd Compare June 2, 2022 14:22

pmuellr commented Jun 2, 2022

View reviewed changes

pmuellr changed the title ~~WIP [ResponseOps]: Refactor alerting task runner - combine loadRuleAttributesAndRun() and validateAndExecuteRule()~~ [ResponseOps]: Refactor alerting task runner - combine loadRuleAttributesAndRun() and validateAndExecuteRule() Jun 2, 2022

pmuellr marked this pull request as ready for review June 2, 2022 16:22

pmuellr requested a review from a team as a code owner June 2, 2022 16:22

pmuellr added the Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) label Jun 2, 2022

pmuellr added Feature:Alerting/RulesFramework Issues related to the Alerting Rules Framework v8.4.0 release_note:skip Skip the PR/issue when compiling release notes backport:skip This commit does not require backporting labels Jun 2, 2022

ymao1 reviewed Jun 2, 2022

View reviewed changes

change markRuleAsSnoozed() to use previously calculated rulesClient

24da47b

ymao1 approved these changes Jun 3, 2022

View reviewed changes

pmuellr mentioned this pull request Jun 7, 2022

[ResponseOps] can we remove some tests after refactoring task runner? #133831

Closed

Merge branch 'main' into alerting/refactor-tr-131544

4948970

ersin-erdal reviewed Jun 8, 2022

View reviewed changes

kibanamachine and others added 2 commits June 13, 2022 10:38

Merge branch 'main' into alerting/refactor-tr-131544

25a484f

collapse prepareAndExecuteRule() into executeRule()

5d00b9c

pmuellr requested a review from ersin-erdal June 13, 2022 19:37

Merge branch 'main' into alerting/refactor-tr-131544

860ed49

pmuellr merged commit 04e259a into elastic:main Jun 14, 2022

doakalexi mentioned this pull request Sep 7, 2022

[ResponseOps][Alerting] can we remove some tests after refactoring task runner? #140127

Merged

1 task

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[ResponseOps]: Refactor alerting task runner - combine loadRuleAttributesAndRun() and validateAndExecuteRule() #132079

[ResponseOps]: Refactor alerting task runner - combine loadRuleAttributesAndRun() and validateAndExecuteRule() #132079

pmuellr commented May 11, 2022 •

edited

Loading

pmuellr Jun 2, 2022

pmuellr Jun 2, 2022

pmuellr Jun 2, 2022

elasticmachine commented Jun 2, 2022

ymao1 Jun 2, 2022

pmuellr Jun 3, 2022

pmuellr Jun 3, 2022

ymao1 Jun 2, 2022

pmuellr Jun 3, 2022

ymao1 Jun 3, 2022

pmuellr Jun 3, 2022

ymao1 Jun 3, 2022

pmuellr Jun 7, 2022

ymao1 left a comment

pmuellr commented Jun 7, 2022

kibana-ci commented Jun 7, 2022

ersin-erdal Jun 8, 2022

pmuellr Jun 13, 2022

pmuellr Jun 13, 2022

pmuellr commented Jun 13, 2022

pmuellr commented Jun 14, 2022

kibana-ci commented Jun 14, 2022

[ResponseOps]: Refactor alerting task runner - combine loadRuleAttributesAndRun() and validateAndExecuteRule() #132079

[ResponseOps]: Refactor alerting task runner - combine loadRuleAttributesAndRun() and validateAndExecuteRule() #132079

Conversation

pmuellr commented May 11, 2022 • edited Loading

Summary

Checklist

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

elasticmachine commented Jun 2, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ymao1 left a comment

Choose a reason for hiding this comment

pmuellr commented Jun 7, 2022

kibana-ci commented Jun 7, 2022

💚 Build Succeeded

Metrics [docs]

Async chunks

Public APIs missing exports

Page load bundle

History

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pmuellr commented Jun 13, 2022

pmuellr commented Jun 14, 2022

kibana-ci commented Jun 14, 2022

💚 Build Succeeded

Metrics [docs]

Async chunks

Public APIs missing exports

Page load bundle

History

pmuellr commented May 11, 2022 •

edited

Loading