Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Security Solution] DetectionRulesClient: return RuleResponse from all methods #186179

Merged
merged 8 commits into from
Jun 21, 2024

Conversation

nikitaindik
Copy link
Contributor

@nikitaindik nikitaindik commented Jun 13, 2024

Partially addresses: #184364

Summary

This PR is a follow-up to PR #185748 and it converts the remaining DetectionRulesClient methods to return RuleResponse.

Changes in this PR:

  • These methods now return RuleResponse instead of internal RuleAlertType type:
    • updateRule
    • patchRule
    • upgradePrebuiltRule
    • importRule

@nikitaindik nikitaindik added refactoring release_note:skip Skip the PR/issue when compiling release notes backport:skip This commit does not require backporting Team:Detections and Resp Security Detection Response Team Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc. Feature:Rule Management Security Solution Detection Rule Management Team:Detection Rule Management Security Detection Rule Management Team v8.15.0 labels Jun 13, 2024
@nikitaindik nikitaindik self-assigned this Jun 13, 2024
@nikitaindik
Copy link
Contributor Author

/ci

@nikitaindik nikitaindik changed the title [Security Solution] DetectionRulesClient: return RuleResponse from all methods [Security Solution] DetectionRulesClient: return RuleResponse from all methods Jun 14, 2024
@nikitaindik
Copy link
Contributor Author

/ci

@nikitaindik
Copy link
Contributor Author

/ci

@banderror banderror removed the backport:skip This commit does not require backporting label Jun 17, 2024
@nikitaindik
Copy link
Contributor Author

/ci

@nikitaindik nikitaindik marked this pull request as ready for review June 18, 2024 21:31
@nikitaindik nikitaindik requested a review from a team as a code owner June 18, 2024 21:31
@nikitaindik nikitaindik requested a review from xcrzx June 18, 2024 21:31
@elasticmachine
Copy link
Contributor

Pinging @elastic/security-detections-response (Team:Detections and Resp)

@elasticmachine
Copy link
Contributor

Pinging @elastic/security-solution (Team: SecuritySolution)

@elasticmachine
Copy link
Contributor

Pinging @elastic/security-detection-rule-management (Team:Detection Rule Management)

Copy link
Contributor

@xcrzx xcrzx left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the refactoring, Nikita 👍 The changes overall look good to me. I have a couple of minor comments to discuss. Let's sync on them over Zoom once you get a chance.

Comment on lines 23 to 24
clients.rulesClient.find.mockResolvedValue(getEmptyFindResult());
clients.rulesClient.update.mockResolvedValue(importedRule);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As rulesClient becomes an internal implementation detail. I think it would be best to start mocking the detectionRulesClient instead.

clients.detectionRulesClient.importRule.mockResolvedValue(importedRule);
clients.detectionRulesClient.importRule.mockResolvedValue({
...getRulesSchemaMock(),
rule_id: importedRule.params.ruleId,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

importedRule.params is an internal data representation of the rules client. Is it possible to avoid relying on it in tests and use our RuleResponse representation?

@@ -39,16 +45,26 @@ export const patchRule = async (

const patchedRule = convertPatchAPIToInternalSchema(nextParams, existingRule);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Out of the scope of this PR, but we need to split convertPatchAPIToInternalSchema into two methods:

  1. Merge patch params with the existing rule
  2. Convert the rule to internal Alerting representation

});
}

/* Trying to convert an internal rule to a RuleResponse object */
const parseResult = RuleResponse.safeParse(transform(importedInternalRule));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to use internalRuleToAPIResponse instead of transform here. If a rule has an incorrect rule type, the validation will fail at the RuleResponse parse stage, but the error would be more cryptic. I suggest reviewing all cases where transform is used and replacing them with internalRuleToAPIResponse.

@nikitaindik nikitaindik requested a review from xcrzx June 20, 2024 15:00
@nikitaindik
Copy link
Contributor Author

Thanks @xcrzx! I have addressed the comments. The PR can be reviewed again.

Copy link
Contributor

@banderror banderror left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Quickly checked the diff, left a couple of minor comments. LGTM!

Comment on lines +56 to +60
const { enabled } = await toggleRuleEnabledOnUpdate(
rulesClient,
existingRule,
nextParams.enabled
);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this function throw exceptions? If yes, I'd suggest to think about if we should add error handling to it so it's safe to call.

The case I'm thinking about is: if the await rulesClient.update call above was successful, how should we handle a failure of the subsequent enable/disable call?

Comment on lines +72 to +82
/* Trying to convert an internal rule to a RuleResponse object */
const parseResult = RuleResponse.safeParse(internalRuleToAPIResponse(importedInternalRule));

if (!parseResult.success) {
throw new RuleResponseValidationError({
message: stringifyZodError(parseResult.error),
ruleId: importedInternalRule.params.ruleId,
});
}

return parseResult.data;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now when this is duplicated in all of the methods, I think it's time to extract this into a function.

Copy link
Contributor

@xcrzx xcrzx left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍 Thank you, @nikitaindik, for addressing my comments

@kibana-ci
Copy link
Collaborator

💛 Build succeeded, but was flaky

Failed CI Steps

Metrics [docs]

✅ unchanged

History

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

cc @nikitaindik

@nikitaindik nikitaindik merged commit 55687dd into elastic:main Jun 21, 2024
39 checks passed
@kibanamachine kibanamachine added the backport:skip This commit does not require backporting label Jun 21, 2024
@nikitaindik
Copy link
Contributor Author

Hey @banderror! I went ahead and merged the PR to let @xcrzx build his changes on top of it more easily. I have added both your suggestions to the checklist in the issue. Will address them in the next PR.

bhapas pushed a commit to bhapas/kibana that referenced this pull request Jun 24, 2024
…m all methods (elastic#186179)

**Partially addresses: elastic#184364

## Summary

This PR is a follow-up to [PR
elastic#185748](elastic#185748) and it converts
the remaining `DetectionRulesClient` methods to return `RuleResponse`.

Changes in this PR:
- These methods now return `RuleResponse` instead of internal
`RuleAlertType` type:
  - `updateRule`
  - `patchRule`
  - `upgradePrebuiltRule`
  - `importRule`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting Feature:Rule Management Security Solution Detection Rule Management refactoring release_note:skip Skip the PR/issue when compiling release notes Team:Detection Rule Management Security Detection Rule Management Team Team:Detections and Resp Security Detection Response Team Team: SecuritySolution Security Solutions Team working on SIEM, Endpoint, Timeline, Resolver, etc. v8.15.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants