[Cases] Case action: Handle closed cases by cnasikas · Pull Request #172709 · elastic/kibana

cnasikas · 2023-12-06T16:54:44Z

Summary

Depends on: #171754

Checklist

Unit or functional tests were updated or

For maintainers

This was checked for breaking API changes and was labeled appropriately

…te --fix'

…o register_case_action

…te --fix'

…o register_case_action

…fix'

cnasikas · 2023-12-08T11:20:13Z

x-pack/plugins/cases/server/client/cases/bulk_update.ts

 * @ignore
 */
-export const update = async (
+export const bulkUpdate = async (


I renamed the method of the case client from update to bulkUpdate to make it clearer what the function does.

cnasikas · 2023-12-08T11:21:30Z

x-pack/plugins/cases/server/connectors/cases/cases_connector.ts


 type GroupedAlertsWithOracleKey = GroupedAlerts & { oracleKey: string };
-type GroupedAlertsWithCaseId = GroupedAlertsWithOracleKey & { caseId: string };
+type GroupedAlertsWithOracleRecords = GroupedAlertsWithOracleKey & { oracleRecord: OracleRecord };


To open new cases for the cases that are closed we need the counter that is stored in the oracle record.

cnasikas · 2023-12-08T11:22:12Z

x-pack/plugins/cases/server/connectors/cases/cases_connector.ts

     */
-    const oracleRecords = await this.upsertOracleRecords(
+    const oracleRecordsMap = await this.upsertOracleRecords(groupedAlertsWithOracleKey);
+    const oracleRecordMapWithTimeWindowHandled = await this.handleTimeWindow(


@adcoelho As we discussed I moved the logic of the time window outside the upsert method.

cnasikas · 2023-12-08T11:22:48Z

x-pack/plugins/cases/server/connectors/cases/cases_connector.ts

    );

-    await this.attachAlertsToCases(casesClient, groupedAlertsWithCases, params);
+    const groupedAlertsWithClosedCasesHandled = await this.handleClosedCases(


We either reopen closed cases or create new ones.

cnasikas · 2023-12-08T11:23:51Z

x-pack/plugins/cases/server/connectors/cases/cases_connector.ts

+    return oracleRecordMap;
+  }
+
+  private async handleTimeWindow(


Same code as before.

cnasikas · 2023-12-08T11:25:00Z

x-pack/plugins/cases/server/connectors/cases/cases_connector.ts

     * We should find a way to fill the custom fields with default values.
     */
    return {
+      id: caseId,


This was a bug.

cnasikas · 2023-12-08T11:25:55Z

x-pack/plugins/cases/server/connectors/cases/cases_connector.ts

+      return casesMapAsArray.find((record) => record.oracleRecord.id === oracleId);
+    };
+
+    const bulkUpdateOracleValidRecords = await this.increaseOracleRecordCounter(


To create new cases, first we need to increase the counter to be able to get the new case ID.

elasticmachine · 2023-12-08T11:26:12Z

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

elasticmachine · 2023-12-08T11:26:14Z

Pinging @elastic/response-ops-cases (Feature:Cases)

x-pack/plugins/cases/server/connectors/cases/cases_connector.ts

adcoelho · 2023-12-19T10:56:14Z

x-pack/plugins/cases/server/connectors/cases/cases_connector.ts

+    );
+
+    /**
+     * TODO: bulkCreate throws an error. Retry on errors.


Maybe this could already be included in this PR?

The logic is more than the regular retry, for some errors(the case exists) we will want to fetch them and do result.set(case.id kinda like the logic in upsert.

I will handle all errors and retries in this PR #173012. I think it is better to do it on another PR as the code can grow a lot and be difficult to follow. I believe is better to retry than fetching the cases. In general, we want each action to be idempotent. This means that if we retry it will not affect the correctness of the case action. In your example, if the case exists this means that another Kibana node (that runs the case action) created the case before this Kibana node managed to do it. If we retry, on the next round the node will find that the case exists and will attach the alerts to that case without trying to create a new one. Retries are useful to break race conditions or transient errors.

I will handle all errors and retries in this PR #173012. I think it is better to do it on another PR as the code can grow a lot and be difficult to follow.

I'm ok with this.

In general, we want each action to be idempotent. This means that if we retry it will not affect the correctness of the case action. In your example, if the case exists this means that another Kibana node (that runs the case action) created the case before this Kibana node managed to do it. If we retry, on the next round the node will find that the case exists and will attach the alerts to that case without trying to create a new one. Retries are useful to break race conditions or transient errors.

Won't it be idempotent anyway? no matter the path followed we always end up with these alerts attached to the case with that ID. Be it if we created the case or if other node did.

You are right on this. It may save us a retry round but I think it will make the code more difficult to follow and the scenario of a conflict should be rare. What do you think of leaving it as it is and when we have the whole picture (retry logic, error handling, etc.) and test a lot we can see if it is worth the optimization?

I am ok with this, my initial suggestion was more about the scope rather than the optimization.

I just elaborated further to make sure I didn't miss some logic in your response 👍

x-pack/plugins/cases/server/connectors/cases/cases_connector.test.ts

js-jankisalvi

code changes looks good 👍

x-pack/plugins/cases/server/connectors/cases/cases_connector.ts

…te --fix'

kibana-ci · 2023-12-20T10:43:28Z

💔 Build Failed

Failed CI Steps

Test Failures

[job] [logs] FTR Configs #43 / cases security and spaces enabled: basic Common update_alert_status should update the status of multiple alerts attached to multiple cases using the cases client
[job] [logs] FTR Configs #43 / cases security and spaces enabled: basic Common update_alert_status should update the status of multiple alerts attached to multiple cases using the cases client
[job] [logs] FTR Configs #88 / cases security and spaces enabled: trial Common update_alert_status should update the status of multiple alerts attached to multiple cases using the cases client
[job] [logs] FTR Configs #88 / cases security and spaces enabled: trial Common update_alert_status should update the status of multiple alerts attached to multiple cases using the cases client
[job] [logs] Jest Tests #21 / update Total comments and alerts calls the attachment service with the right params and returns the expected comments and alerts

Metrics [docs]

‼️ ERROR: no builds found for mergeBase sha [c095b48]

History

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

cc @cnasikas

cnasikas · 2023-12-20T10:49:11Z

packages/kbn-check-mappings-update-cli/current_fields.json

Prettier messed up with the file. This PR will merged into a feature branch.

## Summary This PR: 1. Creates the `CasesConnectorError` error 2. Separate the execution logic by moving the current logic to a new class called `CasesConnectorExecutor` 3. Let the `CasesConnector` class handle only the retry logic of the connector 4. Implements the [Full jitter backoff algorithm](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/) which is used as the retry strategy of the connector Depends on: #172709 ### Checklist Delete any items that are not applicable to this PR. - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios ### For maintainers - [x] This was checked for breaking API changes and was [labeled appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>

## Summary Depends on: #166267, #170326, #169484, #173740, #173763, #178068, #178307, #178600, #180437 PRs: - #168370 - #169229 - #171754 - #172709 - #173012 - #175107 - #175452 - #175505 - #177033 - #178277 - #177139 - #179796 Fixes: #153837 ## Testing Run Kibana with `--run-examples` if you want to use the "Always firing" rule. Create a rule with a case action in observability and the stack. The security solution is not supported. You should not be able to assign a case action in a security solution rule. 1. Test the "Reopen closed cases" configuration. 2. Test the "Grouping by" configuration. Only one field is allowed. Not all fields are persisted in alerts. If you select a field not part of the alert the case action will create a case where the grouping value is set to `unknow`. 3. Test the "Time window" feature. You can comment out the validation to test for shorter times. 4. Verify that the case action is experimental. 5. Verify that based on the rule type the case is created in the correct solution. 6. Verify that you cannot create a rule with the case action on the basic license. 7. Verify that the execution of the case action fails if you do not have permission for cases. Pending work on the system actions framework level to not allow users to create rules with system actions where they do not have permission. 8. Stress test the case action by creating multiple rules. ### Checklist Delete any items that are not applicable to this PR. - [x] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios ### For maintainers - [x] This was checked for breaking API changes and was [labeled appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) ## Release notes Automatically create cases when an alert is triggered. --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: adcoelho <antonio.coelho@elastic.co> Co-authored-by: Janki Salvi <117571355+js-jankisalvi@users.noreply.github.com>

cnasikas and others added 30 commits October 9, 2023 17:16

Register the case action

0e1bfb0

Register the cases oracle

4777f9c

[CI] Auto-commit changed files from 'node scripts/check_mappings_upda…

65a88fa

…te --fix'

Calculate the hash of the record ID

eeb35a6

Merge branch 'register_case_action' of github.com:cnasikas/kibana int…

649dea9

…o register_case_action

Get oracle record

4491476

Rename folder

f4a81a1

Sort grouping definition

5822d73

Increase counter

df77537

Change grouping to record

9955239

Make the rule ID optional in the key

58bc3d6

Better types

581819a

Add version when updating

449a1b7

Improve types

c210a0c

Fix tests

c802637

Merge branch 'case_action' into register_case_action

b249032

Add model version and improve mapping

c120c97

Fix tests

043a9fe

Fix mapping test

a9db13f

[CI] Auto-commit changed files from 'node scripts/check_mappings_upda…

32af9e3

…te --fix'

Merge branch 'case_action' into register_case_action

90acabf

Merge branch 'register_case_action' of github.com:cnasikas/kibana int…

b7605b7

…o register_case_action

Define connector params initial schema

7b27008

Bulk get records

13fd013

Group alerts and bulk get oracle records

69a8778

[CI] Auto-commit changed files from 'node scripts/lint_ts_projects --…

e5c73a3

…fix'

Bulk create records

1ba6117

Merge branch 'ca_part_2' of github.com:cnasikas/kibana into ca_part_2

bf8a32d

Add TODOs

c6982a5

Move bulkGetOrCreateOracleRecords logic to the connector

f184a08

cnasikas mentioned this pull request Dec 8, 2023

[Cases] Case action #168369

Merged

3 tasks

cnasikas commented Dec 8, 2023

View reviewed changes

cnasikas marked this pull request as ready for review December 8, 2023 11:26

cnasikas requested a review from a team as a code owner December 8, 2023 11:26

cnasikas mentioned this pull request Dec 10, 2023

[Cases] Case action: Error handling and retries #173012

Merged

2 tasks

cnasikas changed the title ~~[Cases] Case action: Handle close cases~~ [Cases] Case action: Handle closed cases Dec 12, 2023

adcoelho reviewed Dec 19, 2023

View reviewed changes

x-pack/plugins/cases/server/connectors/cases/cases_connector.ts Outdated Show resolved Hide resolved

adcoelho reviewed Dec 19, 2023

View reviewed changes

x-pack/plugins/cases/server/connectors/cases/cases_connector.ts Show resolved Hide resolved

adcoelho approved these changes Dec 19, 2023

View reviewed changes

js-jankisalvi approved these changes Dec 19, 2023

View reviewed changes

x-pack/plugins/cases/server/connectors/cases/cases_connector.ts Show resolved Hide resolved

cnasikas added 2 commits December 20, 2023 11:31

Merge branch 'case_action' into ca_reopen_cases

8148339

PR feedback

db6ede3

cnasikas force-pushed the ca_reopen_cases branch from 90a3f90 to db6ede3 Compare December 20, 2023 10:04

[CI] Auto-commit changed files from 'node scripts/check_mappings_upda…

7e8d801

…te --fix'

cnasikas requested a review from a team as a code owner December 20, 2023 10:25

cnasikas commented Dec 20, 2023

View reviewed changes

cnasikas merged commit f6491cb into elastic:case_action Dec 20, 2023

cnasikas deleted the ca_reopen_cases branch December 20, 2023 12:37

adcoelho mentioned this pull request Feb 19, 2024

[Cases] Custom fields in case actions #177033

Merged

Conversation

cnasikas commented Dec 6, 2023

Summary

Checklist

For maintainers

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cnasikas Dec 8, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

elasticmachine commented Dec 8, 2023

Uh oh!

elasticmachine commented Dec 8, 2023

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cnasikas Dec 19, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cnasikas Dec 20, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

js-jankisalvi left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

kibana-ci commented Dec 20, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

💔 Build Failed

Failed CI Steps

Test Failures

Metrics [docs]

History

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

cnasikas Dec 8, 2023 •

edited

Loading

cnasikas Dec 19, 2023 •

edited

Loading

cnasikas Dec 20, 2023 •

edited

Loading

kibana-ci commented Dec 20, 2023 •

edited

Loading