[Response Ops][Alerting] Refactor `ExecutionHandler` stage 2 #193807

ymao1 · 2024-09-24T00:29:14Z

Summary

This PR splits the for-loop in the ActionScheduler.run function into the appropriate scheduler classes. Previously, each scheduler had a generateExecutables function that would return an array of executables and the ActionScheduler would loop through the array and convert the executable to a scheduleable action depending on whether it was a per-alert action, summary action or system action. This refactor renames generateExecutables into getActionsToSchedule and moves the logic to convert the executables into a schedulable action into the appropriate scheduler class.

To Verify

Create some rules with per-alert and summary and system actions and verify they are triggered as expected.

ymao1 · 2024-09-26T18:39:59Z

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

-          delete logActions[r.id];
+          const uuid = r.uuid;
+          if (uuid) {
+            actionsToNotLog.push(uuid);


Previously, we were creating a logActions record where the key was the actionId and the value was the information to pass to the event log in order to log the execute-action document. After adding some more unit tests in the PerAlertActionScheduler, I noticed that if we have multiple alerts for the same action or multiple actions that use the same connector, storing this information by the action ID would only allow one event log document to be written, so I switched to passing and using the action UUID instead.

Not understanding why an action not having a uuid is treated differently here. Based on this, but mainly the assignment of actionsToLog below, it seems like we won't log an event log doc for these?

Wondering if we could create a placeholder uuid when the action doesn't have one, just for the action scheduling bits here, so we wouldn't have to worry about it potentially being empty. So I guess in at least ExecutionResponseItem and maybe ExecuteOptions, uuid wouldn't be optional.

I created an issue about the optional typing and added comments about the optional typing here: 32beee0. I can add a placeholder UUID if you think that's better but I think that might cause more confusion in the future

the comment is fine, no placeholder needed, thx!

elasticmachine · 2024-09-27T13:43:41Z

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

ymao1 · 2024-10-01T14:02:38Z

@elasticmachine merge upstream

ymao1 · 2024-10-03T15:54:03Z

@elasticmachine merge upstream

pmuellr · 2024-10-04T16:03:46Z

x-pack/plugins/actions/server/create_execute_function.ts

@@ -31,6 +31,7 @@ interface CreateExecuteFunctionOptions {
 export interface ExecuteOptions
  extends Pick<ActionExecutorOptions, 'params' | 'source' | 'relatedSavedObjects' | 'consumer'> {
  id: string;
+  uuid?: string;


Curious why this is optional. I think it's because for really old rules that haven't been updated since we added the uuid to the actions, it won't be there, and we don't have a migration. But double-checking in case it's BWC or something.

Just from a quick scan of the code, it doesn't seem like we added many tests in this PR that would have a non-existing uuid. Maybe some of the tests already deal with this, that I wouldn't have noticed?

I see one reference to a uuid!, which was just refactor/move from old code - but ... scares me :-). As I take a closer look at this PR, maybe I'll figure out it's ok.

It is typed as optional even though it should always exist on the action :(. I think because we use a single schema in the API and the persistence layer and we don't expect the UUID to be passed into the API but we create one before it reaches the persistence layer.

I found the PR where we added the uuid. For some reason I thought we hadn't done a migration to add to old rules, but we did! Add uuid to rule actions. My fear was we didn't, so an upgrade from an old version wouldn't have uuids, which got me wondering about the cases where you check it.

Seems like something we should fix. Open an issue? No need to fix in this PR (and may be nasty, presumably another type to deal with!).

Created an issue: #195255

…ion-handler-stage-2

kibana-ci · 2024-10-07T15:16:08Z

💛 Build succeeded, but was flaky

Buildkite Build
Commit: 32beee0

Failed CI Steps

Metrics [docs]

✅ unchanged

History

💛 Build #239197 was flaky 71fea9e
💛 Build #238420 was flaky cfb357c
💛 Build #237457 was flaky d3e831f

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

cc @ymao1

ymao1 · 2024-10-09T15:59:01Z

@elasticmachine merge upstream

pmuellr

LGTM, whew!

pmuellr · 2024-10-07T18:58:27Z

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

@@ -3176,7 +3196,7 @@ describe('Task Runner', () => {
      status: 'warning',
      errorReason: `maxExecutableActions`,
      logAlert: 4,
-      logAction: 3,
+      logAction: 5,


curious if this change indicates we were dropping some EL docs when we weren't using the UUIDs ...

Yes, that's correct. If there were N actions configured in a rule with the same connector, then only one execute-action event log doc per alert was written instead of N

ymao1 · 2024-10-09T19:08:00Z

@elasticmachine merge upstream

elasticmachine · 2024-10-09T20:58:18Z

💚 Build Succeeded

Buildkite Build
Commit: 680d6ff

Metrics [docs]

✅ unchanged

History

💚 Build #240791 succeeded 321d58c

cc @ymao1

kibanamachine · 2024-10-09T21:01:37Z

Starting backport for target branches: 8.x

https://github.com/elastic/kibana/actions/runs/11262993933

…#193807) Resolves elastic#186534 ## Summary This PR splits the for-loop in the `ActionScheduler.run` function into the appropriate scheduler classes. Previously, each scheduler had a `generateExecutables` function that would return an array of executables and the `ActionScheduler` would loop through the array and convert the executable to a scheduleable action depending on whether it was a per-alert action, summary action or system action. This refactor renames `generateExecutables` into `getActionsToSchedule` and moves the logic to convert the executables into a schedulable action into the appropriate scheduler class. ## To Verify Create some rules with per-alert and summary and system actions and verify they are triggered as expected. --------- Co-authored-by: Elastic Machine <[email protected]> (cherry picked from commit 9221ab1)

kibanamachine · 2024-10-09T21:06:08Z

💚 All backports created successfully

Status	Branch	Result
✅	8.x

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation

…stage 2 (#193807) (#195676) # Backport This will backport the following commits from `main` to `8.x`: - [[Response Ops][Alerting] Refactor `ExecutionHandler` stage 2 (#193807)](#193807)  ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport)  Co-authored-by: Ying Mao <[email protected]>

Breaking up ActionScheduler.run into subclasses

d3e831f

ymao1 force-pushed the refactor-execution-handler-stage-2 branch from a79dbed to d3e831f Compare September 26, 2024 16:37

ymao1 commented Sep 26, 2024

View reviewed changes

ymao1 changed the title ~~Initial commit refactoring stuff~~ [Response Ops][Alerting] Refactor ExecutionHandler stage 2 Sep 27, 2024

ymao1 self-assigned this Sep 27, 2024

ymao1 marked this pull request as ready for review September 27, 2024 13:43

ymao1 requested a review from a team as a code owner September 27, 2024 13:43

ymao1 requested review from pmuellr and guskovaue September 30, 2024 13:42

Merge branch 'main' into refactor-execution-handler-stage-2

cfb357c

Merge branch 'main' into refactor-execution-handler-stage-2

71fea9e

pmuellr reviewed Oct 4, 2024

View reviewed changes

ymao1 added 2 commits October 7, 2024 09:05

Merge branch 'main' of github.com:elastic/kibana into refactor-execut…

3195eec

…ion-handler-stage-2

Adding comment about optional uuid

32beee0

ymao1 requested a review from pmuellr October 7, 2024 13:26

Merge branch 'main' into refactor-execution-handler-stage-2

321d58c

pmuellr approved these changes Oct 9, 2024

View reviewed changes

Merge branch 'main' into refactor-execution-handler-stage-2

680d6ff

ymao1 merged commit 9221ab1 into elastic:main Oct 9, 2024
37 checks passed

ymao1 deleted the refactor-execution-handler-stage-2 branch October 9, 2024 21:01

kibanamachine mentioned this pull request Oct 9, 2024

[8.x] [Response Ops][Alerting] Refactor `ExecutionHandler` stage 2 (#193807) #195676

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Response Ops][Alerting] Refactor `ExecutionHandler` stage 2 #193807

[Response Ops][Alerting] Refactor `ExecutionHandler` stage 2 #193807

ymao1 commented Sep 24, 2024 •

edited by kibanamachine

Loading

ymao1 Sep 26, 2024

pmuellr Oct 4, 2024

ymao1 Oct 7, 2024

pmuellr Oct 7, 2024

elasticmachine commented Sep 27, 2024

ymao1 commented Oct 1, 2024

ymao1 commented Oct 3, 2024

pmuellr Oct 4, 2024

ymao1 Oct 4, 2024

pmuellr Oct 4, 2024

ymao1 Oct 7, 2024

kibana-ci commented Oct 7, 2024

ymao1 commented Oct 9, 2024

pmuellr left a comment

pmuellr Oct 7, 2024

ymao1 Oct 9, 2024

ymao1 commented Oct 9, 2024

elasticmachine commented Oct 9, 2024

kibanamachine commented Oct 9, 2024

kibanamachine commented Oct 9, 2024

[Response Ops][Alerting] Refactor ExecutionHandler stage 2 #193807

[Response Ops][Alerting] Refactor ExecutionHandler stage 2 #193807

Conversation

ymao1 commented Sep 24, 2024 • edited by kibanamachine Loading

Summary

To Verify

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

elasticmachine commented Sep 27, 2024

ymao1 commented Oct 1, 2024

ymao1 commented Oct 3, 2024

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

kibana-ci commented Oct 7, 2024

💛 Build succeeded, but was flaky

Failed CI Steps

Metrics [docs]

History

ymao1 commented Oct 9, 2024

pmuellr left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ymao1 commented Oct 9, 2024

elasticmachine commented Oct 9, 2024

💚 Build Succeeded

Metrics [docs]

History

kibanamachine commented Oct 9, 2024

kibanamachine commented Oct 9, 2024

💚 All backports created successfully

Questions ?

[Response Ops][Alerting] Refactor `ExecutionHandler` stage 2 #193807

[Response Ops][Alerting] Refactor `ExecutionHandler` stage 2 #193807

ymao1 commented Sep 24, 2024 •

edited by kibanamachine

Loading