-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[RAM][HTTP versioning] Version Bulk Enable Route #179778
[RAM][HTTP versioning] Version Bulk Enable Route #179778
Conversation
Pinging @elastic/response-ops (Team:ResponseOps) |
@elasticmachine merge upstream |
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.
Tested bulk enabling with different rule types and can confirm that the endpoint works correctly, LGTM!
Screen.Recording.2024-04-09.at.16.15.37.mov
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! I left some comments.
x-pack/plugins/alerting/server/routes/rule/apis/bulk_enable/bulk_enable_rules_route.test.ts
Show resolved
Hide resolved
...alerting/server/routes/rule/apis/bulk_enable/transforms/transform_bulk_enable_response/v1.ts
Show resolved
Hide resolved
...alerting/server/routes/rule/apis/bulk_enable/transforms/transform_bulk_enable_response/v1.ts
Show resolved
Hide resolved
response: BulkEnableRulesResult<Params> | ||
): BulkEnableRulesResponseV1<RuleParamsV1>['body'] => { | ||
return { | ||
rules: response.rules.map((rule) => transformRuleToRuleResponseV1<Params>(rule as Rule)), |
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 noticed that before the attributes we were returning were camel case but now it is snake case. Is this considered a breaking change?
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.
Nah we were always returning snake case, the transform was done at the route level thats all.
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.
Unless I miss something, here x-pack/plugins/alerting/server/routes/bulk_enable_rules.ts
we do body: { ...bulkEnableResults, // rest of stuff }
where bulkEnableResults = await rulesClient.bulkEnableRules({ filter, ids });
. The response from bulkEnableRules
is in camel case so the route returns camel case. You can see it from the tests that we were returning camel case and now we are returning snake case. Given that the API is internal I think is fine. I just wanted to be sure we are not introducing a breaking change anywhere.
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.
Yes thankfully we never use the return value of bulkEnableRules
.
x-pack/plugins/alerting/server/application/rule/methods/bulk_enable/bulk_enable_rules.ts
Outdated
Show resolved
Hide resolved
...lugins/alerting/server/application/rule/methods/bulk_enable/types/bulk_enable_rules_types.ts
Show resolved
Hide resolved
x-pack/plugins/alerting/server/application/rule/methods/bulk_enable/bulk_enable_rules.ts
Show resolved
Hide resolved
@@ -208,7 +210,9 @@ describe('bulkEnableRulesRoute', () => { | |||
bulkEnableRulesRoute({ router, licenseState }); | |||
const [_, handler] = router.patch.mock.calls[0]; | |||
|
|||
rulesClient.bulkEnableRules.mockResolvedValueOnce(bulkEnableActionsResult); | |||
rulesClient.bulkEnableRules.mockResolvedValueOnce( | |||
bulkEnableActionsResult as unknown as BulkEnableRulesResult |
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.
Is it possible to avoid the casting here? If in the future we extend the response we will not get notified by TS and we may miss a bug.
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.
Having to do this because we were so lazy with mocking rules in our tests and our types were so bad that it allowed it to work. Now that we are strict with our types these things start to surface.
I could fix it but i feel like thats out of the scope of this PR
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 believe it is easier to do small fixes while we version rules. Otherwise, they will pile up to a point where it will be hard to do it and probably we will forget to do it. Fixing tests feels like part of this PR because we change the types and tests should follow. I am not advocating fixing everything just things that will help us prevent bugs in the future. If the fix involves fixing code unrelated to the rulesClient.bulkEnableRules
like the issue you said about SanitizedRule
then at least we can type the bulkEnableActionsResult
and keep your casting so in the future will warn us that we need to take into account more attributes. Wdyt?
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.
Tested and is working as expected. LGTM!
💛 Build succeeded, but was flaky
Failed CI StepsTest FailuresMetrics [docs]Public APIs missing exports
History
To update your PR or re-run it, just comment with: |
💔 All backports failed
Manual backportTo create the backport manually run:
Questions ?Please refer to the Backport tool documentation |
Summary
Parent Issue: #157883
Issue: #179669
Versions the
PATCH /internal/alerting/rules/_bulk_enable
endpoint with added input and output validation.Checklist