-
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
[Cases] Make metrics routes internal #162506
Conversation
Pinging @elastic/response-ops (Team:ResponseOps) |
Pinging @elastic/response-ops-cases (Feature:Cases) |
Fixed failing tests that were using the old url. Corrected types for single case metrics features.
d0d5180
to
883dfd0
Compare
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.
🚀
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.
Threat hunting explore team changes LGTM!
💛 Build succeeded, but was flaky
Failed CI StepsTest Failures
Metrics [docs]Public APIs missing comments
Async chunks
Page load bundle
History
To update your PR or re-run it, just comment with: cc @adcoelho |
Fixes elastic#162406 ## Summary - Made `getCaseMetrics` and `getCasesMetrics` internal APIs. - There was no documentation to begin with so there was none to remove. - The allowed/available `features` now come from the `CaseMetricsFeature` _enum_ instead of being hardcoded everywhere. - We now **also** check for the values passed to the `features` field in case metrics requests using io-ts. - There was already some validation before which I decided to leave. When doing `buildHandlers` the function `checkAndThrowIfInvalidFeatures` is always called. Right now, this is only used by `getCasesMetrics` and `getCaseMetrics` where we already decode the params so that validation is redundant, but if it starts being used somewhere else it will be nice to have this extra security guarantee. ### Release Notes The get case metrics APIs are now internal. --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Fixes #162406
Summary
getCaseMetrics
andgetCasesMetrics
internal APIs.features
now come from theCaseMetricsFeature
enum instead of being hardcoded everywhere.features
field in case metrics requests using io-ts.buildHandlers
the functioncheckAndThrowIfInvalidFeatures
is always called. Right now, this is only used bygetCasesMetrics
andgetCaseMetrics
where we already decode the params so that validation is redundant, but if it starts being used somewhere else it will be nice to have this extra security guarantee.Release Notes
The get case metrics APIs are now internal.