[Core] Explicit typings for request handler context#88718
[Core] Explicit typings for request handler context#88718mshustov merged 50 commits intoelastic:masterfrom
Conversation
Context implementation will be simplified in follow-up.
jportner
left a comment
There was a problem hiding this comment.
Security and Spaces plugin changes LGTM
justinkambic
left a comment
There was a problem hiding this comment.
Changes to Uptime app LGTM.
chrisronline
left a comment
There was a problem hiding this comment.
LGTM for stack monitoring
streamich
left a comment
There was a problem hiding this comment.
AppServices changes LGTM.
rylnd
left a comment
There was a problem hiding this comment.
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.
XavierM
left a comment
There was a problem hiding this comment.
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.
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.
@cnasikas no idea, this comment was copied from the old declaration https://github.com/elastic/kibana/pull/88718/files/6334f55c5e4a8af3cc93d10345cb2340e14fc437#diff-e0b5bc10c412de3c7f41b1647bfefd4c32bf449eb235c1b257e8eac0daf6da80L18
paul-tavares
left a comment
There was a problem hiding this comment.
LGTM from a Security Solution Endpoint Management standpoint
jloleysens
left a comment
There was a problem hiding this comment.
ES UI changes look good to me!
afharo
left a comment
There was a problem hiding this comment.
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.
| string, | ||
| { | ||
| provider: IContextProvider<THandler, keyof HandlerContextType<THandler>>; | ||
| provider: IContextProvider<any, any>; |
There was a problem hiding this comment.
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.
pgayvallet
left a comment
There was a problem hiding this comment.
LGTM. That was something!
| import { Server } from '@hapi/hapi'; | ||
| import { pick } from '@kbn/std'; | ||
|
|
||
| import type { RequestHandlerContext } from 'src/core/server'; |
There was a problem hiding this comment.
NIT: can we use relative import here?
There was a problem hiding this comment.
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
| P = unknown, | ||
| Q = unknown, | ||
| B = unknown, | ||
| Context extends RequestHandlerContext = RequestHandlerContext, |
There was a problem hiding this comment.
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);
| expect(fetch).toBeCalledWith(mockConfig.optInStatusUrl, { | ||
| method: 'post', | ||
| body: mockOptInStatus, | ||
| body: '["mock_opt_in_hashed_value"]', |
There was a problem hiding this comment.
fetch body doesn't accept string[], but string. after the fix, the test reflects the change.
| await fetch(optInStatusUrl, { | ||
| method: 'post', | ||
| body: optInStatus, | ||
| body: JSON.stringify(optInStatus), |
There was a problem hiding this comment.
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
RequestHandlerContexttype.If a plugin extends
RequestHandlerContextwith 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
contextparameter explicitly.Before:
After: