-
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
[data / saved query] BWCA all the routes #158790
[data / saved query] BWCA all the routes #158790
Conversation
* These types are used to define the shape of the response from the saved query API | ||
*/ | ||
|
||
// @ts-expect-error |
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 don't know why this is necessary - this type is essentially copied from MatchAllFilterMeta
where it works.
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.
Bizarrely, this seems to be caused by Filter
being an interface instead of a type. It looks like that's why packages/kbn-es-query/src/filters/build_filters/types.ts
uses a type with // eslint-disable-next-line @typescript-eslint/consistent-type-definitions
instead:
kibana/packages/kbn-es-query/src/filters/build_filters/types.ts
Lines 87 to 94 in ef524bb
// eslint-disable-next-line @typescript-eslint/consistent-type-definitions | |
export type Filter = { | |
$state?: { | |
store: FilterStateStore; | |
}; | |
meta: FilterMeta; | |
query?: Record<string, any>; | |
}; |
I have no idea why the compiler doesn't like this though 🤔
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'm mostly confused because I made sure my copied Filter
is also a type
and yet the compiler still complains.
Pinging @elastic/kibana-data-discovery (Team:DataDiscovery) |
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.
The changes are looking good overall, just a couple of validation issues to fix up and a few comments.
* These types are used to define the shape of the response from the saved query API | ||
*/ | ||
|
||
// @ts-expect-error |
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.
Bizarrely, this seems to be caused by Filter
being an interface instead of a type. It looks like that's why packages/kbn-es-query/src/filters/build_filters/types.ts
uses a type with // eslint-disable-next-line @typescript-eslint/consistent-type-definitions
instead:
kibana/packages/kbn-es-query/src/filters/build_filters/types.ts
Lines 87 to 94 in ef524bb
// eslint-disable-next-line @typescript-eslint/consistent-type-definitions | |
export type Filter = { | |
$state?: { | |
store: FilterStateStore; | |
}; | |
meta: FilterMeta; | |
query?: Record<string, any>; | |
}; |
I have no idea why the compiler doesn't like this though 🤔
…kime/kibana into saved_query_better_route_definition
@davismcphee I overlooked this for a few days, its ready for another looks. |
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 again locally and all is working as expected now 👍 thanks for the changes, LGTM!
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.
Changes LGTM!
@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.
Looks great 🚀 and works well as well. Left a comment about something I was not sure.
@@ -15,7 +17,7 @@ export const createSavedQuery = ( | |||
) => | |||
rootRequest<SavedQuery>({ | |||
method: 'POST', | |||
url: '/api/saved_query/_create', | |||
url: `${SAVED_QUERY_BASE_URL}/_create`, |
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 am not sure so I am writing here for your consideration if you think it makes sense for security solution to use createQuery
function instead of calling this API directly.
Although, if we go down that way, createQuery
would need to expose version
as well so that users can easily pass it.
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.
Either the REST api should be used or the plugin api contract. This looks like a test setup - REST api usage looks fine to me but your team might also decide something different.
💛 Build succeeded, but was flaky
Failed CI StepsTest Failures
Metrics [docs]Page load bundle
Unknown metric groupsESLint disabled line counts
Total ESLint disabled count
History
To update your PR or re-run it, just comment with: cc @mattkime |
Summary
All routes