-
-
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
deps: update fastify to v4.26.2 #6626
Conversation
@@ -84,34 +84,34 @@ export class RestApiServer { | |||
// Log all incoming request to debug (before parsing). TODO: Should we hook latter in the lifecycle? https://www.fastify.io/docs/latest/Lifecycle/ | |||
// Note: Must be an async method so fastify can continue the release lifecycle. Otherwise we must call done() or the request stalls | |||
server.addHook("onRequest", async (req, _res) => { | |||
const {operationId} = req.routeConfig as RouteConfig; | |||
this.logger.debug(`Req ${req.id as string} ${req.ip} ${operationId}`); | |||
const operationId = req.routeSchema.operationId as string; |
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.
It makes more sense to get this from schema as operationId
is already part of standard type definition. We can drop including it in custom routeConfig
altogether but will do that on the refactor branch
metrics?.responseTime.observe({operationId}, res.getResponseTime() / 1000); | ||
const operationId = req.routeSchema.operationId as string; | ||
this.logger.debug(`Res ${req.id} ${operationId} - ${res.raw.statusCode}`); | ||
metrics?.responseTime.observe({operationId}, res.elapsedTime / 1000); |
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.
As of latest release getResponseTime()
has been deprecated (fastify/fastify#5263) and will be removed in the next major release (v5)
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## unstable #6626 +/- ##
=========================================
Coverage 61.70% 61.70%
=========================================
Files 556 556
Lines 58799 58799
Branches 1886 1886
=========================================
Hits 36283 36283
Misses 22475 22475
Partials 41 41 |
Performance Report✔️ no performance regression detected 🚀🚀 Significant benchmark improvement detected
Full benchmark results
|
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.
Would be interesting to see what would be the impact of removing the extra Buffer.from
.
Also worth noting that although cli
depends on fastify
(for test), it's not declared in their package.json
.
Good catch! I think this PR is a good place to fix this, also updated for light-client package which uses fastify in tests as well
Will do some testing, haven't looked at actual performance difference yet |
🎉 This PR is included in v1.18.0 🎉 |
Motivation
The latest version includes proper support for returning
Uint8Array
from handler and will efficiently convert it to aBuffer
internally without copying the underlyingArrayBuffer
.The current approach we use is copying it instead which is not ideal
lodestar/packages/api/src/beacon/server/beacon.ts
Line 26 in 5577996
But I think we can keep this as is for now. I mainly want to test against latest fastify version on the api client refactor branch without increasing the diff there even more by updating dependencies.
Description
Update fastify to v4.26.2 which includes fix for returning
Uint8Array
from handlers (fastify/fastify#5124)