-
-
Notifications
You must be signed in to change notification settings - Fork 289
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
feat: add syncing_status query parameter to eth/v1/node/health #5790
Changes from all commits
5f25f03
0cbccc2
c4e4ace
ab7d42e
50d91e9
a127714
e1cbec4
0f2444e
900743a
3abda75
f07b469
35ab535
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||
---|---|---|---|---|
|
@@ -7,7 +7,7 @@ export type APIClientHandler = (...args: any) => PromiseLike<ApiClientResponse>; | |||
export type APIServerHandler = (...args: any) => PromiseLike<unknown>; | ||||
|
||||
export type ApiClientSuccessResponse<S extends keyof any, T> = {ok: true; status: S; response: T; error?: never}; | ||||
export type ApiClientSErrorResponse<S extends Exclude<HttpStatusCode, HttpSuccessCodes>> = { | ||||
export type ApiClientErrorResponse<S extends Exclude<HttpStatusCode, HttpSuccessCodes>> = { | ||||
ok: false; | ||||
status: S; | ||||
response?: never; | ||||
|
@@ -18,17 +18,16 @@ export type ApiClientResponse< | |||
E extends Exclude<HttpStatusCode, HttpSuccessCodes> = Exclude<HttpStatusCode, HttpSuccessCodes>, | ||||
> = | ||||
| {[K in keyof S]: ApiClientSuccessResponse<K, S[K]>}[keyof S] | ||||
| {[K in E]: ApiClientSErrorResponse<K>}[E] | ||||
| ApiClientSErrorResponse<HttpStatusCode.INTERNAL_SERVER_ERROR>; | ||||
| {[K in E]: ApiClientErrorResponse<K>}[E] | ||||
| ApiClientErrorResponse<HttpStatusCode.INTERNAL_SERVER_ERROR>; | ||||
|
||||
export type ApiClientResponseData<T extends ApiClientResponse> = T extends {ok: true; response: infer R} ? R : never; | ||||
|
||||
export type GenericRequestObject = Record<string, unknown>; | ||||
export type GenericResponseObject = {code: (code: number) => void}; | ||||
export type GenericOptions = Record<string, unknown>; | ||||
|
||||
export type ServerApi<T extends Record<string, APIClientHandler>> = { | ||||
[K in keyof T]: ( | ||||
...args: [...args: Parameters<T[K]>, req?: GenericRequestObject, res?: GenericResponseObject] | ||||
...args: [...args: Parameters<T[K]>, opts?: GenericOptions] | ||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I removed req / res but added generic opts instead, we have API implementations that pass additional options, like
|
||||
) => Promise<ApiClientResponseData<Resolves<T[K]>>>; | ||||
}; | ||||
|
||||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -26,7 +26,7 @@ export function getFetchOptsSerializer<Fn extends (...args: any) => any, ReqType | |
return { | ||
url: urlFormater(req.params ?? {}), | ||
method: routeDef.method, | ||
query: req.query, | ||
query: Object.keys(req.query ?? {}).length ? req.query : undefined, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Fixes appending '?' to URL if query params are omitted, e.g. I would assume most/(all) HTTP servers will ignore this anyways, but it might be misleading if req.url is logged on the server. |
||
body: req.body as unknown, | ||
headers: req.headers, | ||
routeId, | ||
|
@@ -80,14 +80,17 @@ export function generateGenericJsonClient< | |
} | ||
} catch (err) { | ||
if (err instanceof HttpError) { | ||
return {ok: false, error: {code: err.status, message: err.message, operationId: routeId}} as ReturnType< | ||
Api[keyof Api] | ||
>; | ||
return { | ||
ok: false, | ||
status: err.status, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Assuming this was just missed previously as the code here is not really type-safe, didn't find a quick solution to fix that but we should always set status in client response. |
||
error: {code: err.status, message: err.message, operationId: routeId}, | ||
} as ReturnType<Api[keyof Api]>; | ||
} | ||
|
||
if (err instanceof TimeoutError) { | ||
return { | ||
ok: false, | ||
status: HttpStatusCode.INTERNAL_SERVER_ERROR, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This status code is kinda wrong but 408 would also be wrong as it would indicate a server timeout whereas this error happens due to client timeout. If server doesn't respond within client timeout we can assume a server issue, setting 500 here is the most accurate. Alternative would be to just throw the error here but this makes the error logs less informative if a timeout happens. |
||
error: {code: HttpStatusCode.INTERNAL_SERVER_ERROR, message: err.message, operationId: routeId}, | ||
} as ReturnType<Api[keyof Api]>; | ||
} | ||
|
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 would recommend moving the range check in the schema.
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.
Do you have an example API that does this? Based on current types this is not possible as far as I can see, we only support pre-defined schemas
lodestar/packages/api/src/utils/schema.ts
Line 25 in a127714
We enforce basic validation through schema but the error response and logging is not ideal in my opinion
JSON API response
Schema validation error
API error
Error log
Schema validation error
API error
In both cases as it is right now, it is better to use API error. Schema validation could be made more flexible but there are not that many values in the spec that enforce things like minimum / maximum.