Open miltonhultgren opened 3 weeks ago
Pinging @elastic/obs-knowledge-team (Team:obs-knowledge)
@awahab07 Just as an example, if we change this line:
conflict(options?: ErrorHttpResponseOptions): IKibanaResponse;
to
conflict(options?: ErrorHttpResponseOptions): IKibanaResponse<never>;
Then that seems to fix it but I don't know what the impact of this would be, or if it semantically makes sense. I believe it does (there will never be a payload because the HTTP client will interpret those status codes as errors and throw instead), but we need to validate that with the Core team perhaps.
We have added support for returning the result's from
KibanaResponseFactory
. This works well with our inference when using theok
function since we can unwrap the object we pass back.But when using any of the error codes, our inference breaks down because they are typed as
any
, so which ends up overshadowing any other type information we try to provide.We should find some way to alter these types or make them changeable so that we can better infer the shape of the error objects. Perhaps if they are changed to
unknown
ornever
instead that could improve the situation.Note: In general it is better for performance to define explicit return types on the handler since it means less inference work for the TypeScript compiler to do