Update ES client to 8.1.0-canary.2#119791
Conversation
stratoula
left a comment
There was a problem hiding this comment.
Viz editors changes LGTM!
ashokaditya
left a comment
There was a problem hiding this comment.
security_solution changes LGTM. I only have a few suggestions for removing redundant union types that use undefined.
| sortOrder?: estypes.SearchSortOrder; | ||
| searchAfterSortIds: estypes.SearchSortResults | undefined; | ||
| sortOrder?: estypes.SortOrder; | ||
| searchAfterSortIds: estypes.SortResults | undefined; |
There was a problem hiding this comment.
| searchAfterSortIds: estypes.SortResults | undefined; | |
| searchAfterSortIds?: estypes.SortResults; |
There was a problem hiding this comment.
@ashokaditya Happy to accept those changes. However, IMO, they are not exactly the same:
AFAIK, searchAfterSortIds: estypes.SortResults | undefined; enforces the property to be present but it accepts undefined. Setting a property as optional means that the property might not be provided.
It's a small difference, but depending on where it's used, it can catch some errors.
If you're happy with making the property optional, I'll gladly accept your suggestion :)
EDIT: I noticed about the agreement with Pierre. I also agree that it's better to make these changes in a separate PR.
There was a problem hiding this comment.
@afharo yes quite right. At least in these cases, the types look like they are optional. Although it does make sense to explicitly define this so that the param is explicitly assigned undefined when that method is invoked if that is what is intended 👍
x-pack/plugins/security_solution/server/lib/detection_engine/signals/single_search_after.ts
Show resolved
Hide resolved
x-pack/plugins/security_solution/server/lib/detection_engine/signals/utils.ts
Show resolved
Hide resolved
...ty_solution/server/search_strategy/security_solution/factory/cti/event_enrichment/helpers.ts
Show resolved
Hide resolved
| `); | ||
| expectSnapshot( | ||
| response.body.traceDocs.map((doc) => | ||
| // @ts-expect-error Property 'processor' does not exist on type 'Profile'. |
There was a problem hiding this comment.
this (and the other @ts-expect-error before) indicate that the request body is not valid. I'll have a look.
dgieselaar
left a comment
There was a problem hiding this comment.
Approving on behalf of APM UI, @walterra will also have a look at the changes in APM's correlations code (thank you Walter!)
|
Relaunching the tests because it looks like they fail due to timeouts in Buildkite (cc @elastic/kibana-operations) |
|
@elasticmachine merge upstream |
justinkambic
left a comment
There was a problem hiding this comment.
Uptime change LGTM!
x-pack/plugins/security_solution/common/endpoint/data_loaders/index_fleet_server.ts
Outdated
Show resolved
Hide resolved
…index_fleet_server.ts Co-authored-by: Steph Milovic <stephanie.milovic@elastic.co>
stephmilovic
left a comment
There was a problem hiding this comment.
LGTM for threat hunting, thank you
walterra
left a comment
There was a problem hiding this comment.
Transforms/ML/APM Correlations LGTM
walterra
left a comment
There was a problem hiding this comment.
Transforms/ML/APM Correlations LGTM
|
@elasticmachine merge upstream |
|
I double-checked the changes for the 2 pending reviewers. The changes are minimal:
I'll merge after green CI. |
💚 Build Succeeded
Metrics [docs]Public APIs missing comments
Async chunks
Public APIs missing exports
Page load bundle
History
To update your PR or re-run it, just comment with: cc @afharo |
pjhampton
left a comment
There was a problem hiding this comment.
🌔 🚀 ✨ LGTM ✨ 🚀 🌔
Security telemetry changes look good!
Summary
Closes #119454
Closes #116111
Important changes:
_typemeta field is removed Remove support for _type in searches elasticsearch#68564TAggregationsgeneric Aggregations should be a generic in responses elasticsearch-js#1596asStreamconfiguration option Add asStream support elastic-transport-js#34Aggregations
In this PR, I declared definitions as
I use
extendsto enforcebucketscompatbility. ES client type definitions definebucketstype asso we have to specify explicitly the bucket type we expect - object or array-based.
Hopefully, in the future, we will be able to infer a response type from a request type. For now, we declare it explicitly.