-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
[Security Solution] DetectionRulesClient
: return RuleResponse
from all methods
#186179
Conversation
/ci |
RuleResponse
from all methodsDetectionRulesClient
: return RuleResponse
from all methods
2b9f24a
to
c838747
Compare
/ci |
c838747
to
bf56a9a
Compare
/ci |
…ce it won't do anything
9294d6c
to
8d3fe01
Compare
/ci |
Pinging @elastic/security-detections-response (Team:Detections and Resp) |
Pinging @elastic/security-solution (Team: SecuritySolution) |
Pinging @elastic/security-detection-rule-management (Team:Detection Rule Management) |
There was a problem hiding this 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.
clients.rulesClient.find.mockResolvedValue(getEmptyFindResult()); | ||
clients.rulesClient.update.mockResolvedValue(importedRule); |
There was a problem hiding this comment.
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, |
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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:
- Merge patch params with the existing rule
- Convert the rule to internal Alerting representation
}); | ||
} | ||
|
||
/* Trying to convert an internal rule to a RuleResponse object */ | ||
const parseResult = RuleResponse.safeParse(transform(importedInternalRule)); |
There was a problem hiding this comment.
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
.
Thanks @xcrzx! I have addressed the comments. The PR can be reviewed again. |
There was a problem hiding this 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!
const { enabled } = await toggleRuleEnabledOnUpdate( | ||
rulesClient, | ||
existingRule, | ||
nextParams.enabled | ||
); |
There was a problem hiding this comment.
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?
/* 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; |
There was a problem hiding this comment.
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.
There was a problem hiding this 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
💛 Build succeeded, but was flaky
Failed CI StepsMetrics [docs]
History
To update your PR or re-run it, just comment with: cc @nikitaindik |
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. |
…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`
Partially addresses: #184364
Summary
This PR is a follow-up to PR #185748 and it converts the remaining
DetectionRulesClient
methods to returnRuleResponse
.Changes in this PR:
RuleResponse
instead of internalRuleAlertType
type:updateRule
patchRule
upgradePrebuiltRule
importRule