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

[RAM][HTTP versioning] Version Bulk Enable Route #179778

Merged
merged 10 commits into from
Apr 30, 2024

Conversation

JiaweiWu
Copy link
Contributor

@JiaweiWu JiaweiWu commented Apr 1, 2024

Summary

Parent Issue: #157883
Issue: #179669

Versions the PATCH /internal/alerting/rules/_bulk_enable endpoint with added input and output validation.

Checklist

@JiaweiWu JiaweiWu added release_note:skip Skip the PR/issue when compiling release notes Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) Feature:Alerting/RulesManagement Issues related to the Rules Management UX v8.14.0 labels Apr 1, 2024
@JiaweiWu JiaweiWu requested a review from a team as a code owner April 1, 2024 22:34
@elasticmachine
Copy link
Contributor

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

@JiaweiWu
Copy link
Contributor Author

JiaweiWu commented Apr 1, 2024

@elasticmachine merge upstream

Copy link
Member

@umbopepato umbopepato left a 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

Copy link
Member

@cnasikas cnasikas left a 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.

response: BulkEnableRulesResult<Params>
): BulkEnableRulesResponseV1<RuleParamsV1>['body'] => {
return {
rules: response.rules.map((rule) => transformRuleToRuleResponseV1<Params>(rule as Rule)),
Copy link
Member

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?

Copy link
Contributor Author

@JiaweiWu JiaweiWu Apr 18, 2024

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.

Copy link
Member

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.

Copy link
Contributor Author

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.

@@ -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
Copy link
Member

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.

Copy link
Contributor Author

@JiaweiWu JiaweiWu Apr 18, 2024

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

Copy link
Member

@cnasikas cnasikas Apr 18, 2024

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?

Copy link
Member

@cnasikas cnasikas left a 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!

@JiaweiWu JiaweiWu linked an issue Apr 29, 2024 that may be closed by this pull request
@kibana-ci
Copy link
Collaborator

💛 Build succeeded, but was flaky

Failed CI Steps

Test Failures

  • [job] [logs] Jest Tests #9 / usePostPushToService refresh the case after pushing

Metrics [docs]

Public APIs missing exports

Total count of every type that is part of your API that should be exported but is not. This will cause broken links in the API documentation system. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats exports for more detailed information.

id before after diff
alerting 55 56 +1

History

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

@JiaweiWu JiaweiWu merged commit 4b4c573 into elastic:main Apr 30, 2024
34 checks passed
@kibanamachine
Copy link
Contributor

💔 All backports failed

Status Branch Result
8.14 Backport failed because of merge conflicts

Manual backport

To create the backport manually run:

node scripts/backport --pr 179778

Questions ?

Please refer to the Backport tool documentation

@JiaweiWu JiaweiWu removed the v8.14.0 label Apr 30, 2024
@kibanamachine kibanamachine added the backport:skip This commit does not require backporting label Apr 30, 2024
yuliacech pushed a commit to yuliacech/kibana that referenced this pull request May 3, 2024
## Summary
Parent Issue: elastic#157883
Issue: elastic#179669

Versions the `PATCH /internal/alerting/rules/_bulk_enable` endpoint with
added input and output validation.

### Checklist
- [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

---------

Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
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:Alerting/RulesManagement Issues related to the Rules Management UX release_note:skip Skip the PR/issue when compiling release notes Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) v8.15.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[RAM] Version Bulk Enable API
6 participants