-
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
[Core] Explicit typings for request handler context #88718
[Core] Explicit typings for request handler context #88718
Conversation
Context implementation will be simplified in follow-up.
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 to Uptime app 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.
LGTM for stack monitoring
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.
AppServices 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.
Lists and Detections changes LGTM! I'd like to get (and have requested) approval from someone(s) more familiar with the Cases and Endpoint code, 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.
LGTM for Case and timeline
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 for Case and Timeline
case: CaseRequestContext; | ||
actions: ActionsApiRequestHandlerContext; | ||
// TODO: Remove when triggers_ui do not import case's types. | ||
// PR https://github.com/elastic/kibana/pull/84587. |
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.
Super nit -> The comments should be removed right? To my understanding it is required to declare all plugin dependencies context and we should not remove the securitySolution
, right?
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.
@cnasikas no idea, this comment was copied from the old declaration https://github.com/elastic/kibana/pull/88718/files/6334f55c5e4a8af3cc93d10345cb2340e14fc437#diff-e0b5bc10c412de3c7f41b1647bfefd4c32bf449eb235c1b257e8eac0daf6da80L18
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 from a Security Solution Endpoint Management standpoint
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.
ES UI changes look good to me!
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.
Code LGTM! I think we'll need a follow-up to fix the @ts-expect-error
bits. But I think we can move on for now to unblock the TS refs efforts.
{ | ||
provider: IContextProvider<THandler, keyof HandlerContextType<THandler>>; | ||
provider: IContextProvider<any, any>; |
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.
Super-NIT: I think this generalization of the types makes TS lose the references to THandler
. And that is causing the arity problems down the line. IMO, we can revisit these types later to unblock the TS References migrations.
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. That was something!
@@ -11,6 +11,7 @@ import { first, map } from 'rxjs/operators'; | |||
import { Server } from '@hapi/hapi'; | |||
import { pick } from '@kbn/std'; | |||
|
|||
import type { RequestHandlerContext } from 'src/core/server'; |
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.
NIT: can we use relative import here?
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.
we can, but RequestHandlerContext
declared in 'src/core/server/index.ts'
. I'd prefer we move it to not sure what is the best place to keep it, http
in a separate PRRequestHandlerContext
is Kibana application-specific type, not related to http
service
@@ -341,10 +349,11 @@ export type RequestHandler< | |||
P = unknown, | |||
Q = unknown, | |||
B = unknown, | |||
Context extends RequestHandlerContext = RequestHandlerContext, |
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.
Some plugins are declaring their handlers outside of the route registration, so the handler's generics are not inferred
e.g
const handler = ...
router.get(config, handler);
body: mockOptInStatus, | ||
body: '["mock_opt_in_hashed_value"]', |
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.
NIT: why the 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.
fetch body doesn't accept string[]
, but string
. after the fix, the test reflects the change.
@@ -35,7 +35,7 @@ export async function sendTelemetryOptInStatus( | |||
|
|||
await fetch(optInStatusUrl, { | |||
method: 'post', | |||
body: optInStatus, | |||
body: JSON.stringify(optInStatus), |
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.
Probably because of the removed ts-ignore
?
💚 Build SucceededMetrics [docs]Module Count
Page load bundle
History
To update your PR or re-run it, just comment with: |
* move context to server part. couple with RequestHandlerContext Context implementation will be simplified in follow-up. * adopt core code * adopt bfetch code * adopt data code * adopt search examples * adopt vis_type_timelion * adopt vis_type_timeseries * adopt plugin functional tests * adopt actions * adopt alerting plugin * adopt APM plugin * adopt beats_management * adopt case plugin * adopt cross_cluster_replication * adopt data_enhanced * adopt event_log * adopt global_search * adopt index_management * adopt infra * adopt licensing * adopt lists * adopt logstash * adopt reporting * adopt observability * adopt monitoring * adopt rollup * adopt so tagging * adopt security * adopt security_solutions * adopt watcher * adopt uptime * adopt spaces * adopt snapshot_restore * adopt features changes * mute error when null used to extend context * update docs * small cleanup * add type safety for return type * refactor registerRouteHandlerContext type * update docs * update license header * update docs * fix type error. fetch body does not accept array of strings * fix telemetry test * remove unnecessary ts-ignore * address comments * update docs # Conflicts: # docs/development/plugins/data/server/kibana-plugin-plugins-data-server.plugin.start.md # src/plugins/data/server/server.api.md # x-pack/plugins/monitoring/server/plugin.ts
Summary
Part of #57588
This PR removes interface augmentation pattern for
RequestHandlerContext
type.If a plugin extends
RequestHandlerContext
with a custom property or accesses a property defined by a dependency, it should declare a context type explicitly.Before:
After:
The benefits of the approach:
Plugin API Changes
Whenever Kibana needs to get access to data saved in elasticsearch, it should perform a check whether an end-user has access to the data.
On the server-side, API requiring impersonation with an incoming request, are exposed via context argument of request handler:
Starting from the current version your plugin should declare an interface of this
context
parameter explicitly.Before:
After: