[RAM][Maintenance Window] Maintenance window scoped query task manager changes

[JiaweiWu]

Summary

Resolves: #164255

This is part 3/3 of the maintenance window scoped query PR. This change contains only the task manager changes and has no dependency on other PRs. To test the changes in this PR, I recommend using this branch #172117 which has all of the frontend changes and the changes in this PR.

This PR adds support for maintenance window scoped query in the task manager. To do this, we need to perform a fetch on the new persisted alerts with the scoped query as filters. We then must save these alerts again with the update maintenance window IDs.

Checklist

• Unit or functional tests were updated or added to match the most common scenarios

[elasticmachine]

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

[ymao1]

Did an initial code review and a bare bones verification and I think the approach makes sense overall given the constraints we have to work with. Left a few nits

[JiaweiWu]

@elasticmachine merge upstream

[ymao1]

Code is looking good! Left a bunch of nits and then one comment about handling possible unhandled promise rejection.

To verify, I created a maintenance window that applied to stack rules with kibana.alert.name: "test". Then I created an ES query rule with name "test" and with some logging, see it generate a new alert and the appropriate maintenance window ID gets set for the new alert in memory. However, when I check the alert document, I see "kibana.alert.maintenance_window_ids": null,, so it looks like the update by query is not working as expected?

[ymao1]

can we add a test for behavior when ES throws an error on the update by query?

[JiaweiWu]

I added a test to the inner function since we never await on updateAlertsMaintenanceWindowIdByScopedQuery so it's a bit hard to test the reject case.

[JiaweiWu]

@elasticmachine merge upstream

[JiaweiWu]

Code is looking good! Left a bunch of nits and then one comment about handling possible unhandled promise rejection.

To verify, I created a maintenance window that applied to stack rules with kibana.alert.name: "test". Then I created an ES query rule with name "test" and with some logging, see it generate a new alert and the appropriate maintenance window ID gets set for the new alert in memory. However, when I check the alert document, I see "kibana.alert.maintenance_window_ids": null,, so it looks like the update by query is not working as expected?

I had a small bug in the updateByQuery script. It has been fixed and I added a test to verify that the alert docs are indeed updated.

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: cca5851

Metrics [docs]

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id	before	after	diff
alerting	782	783	+1

Unknown metric groups

API count

id	before	after	diff
alerting	813	814	+1

History

• 💔 Build #181040 failed b41ec7a
• 💔 Build #181016 failed fe90441
• 💔 Build #180766 failed c740439
• 💔 Build #180761 failed 96b9c50
• 💛 Build #180669 was flaky 697e1e4

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

[ymao1]

LGTM. Verified that MW with scoped query is correctly applied to new alerts that match the query and not applied to new alerts that don't match the query.