-
-
Notifications
You must be signed in to change notification settings - Fork 320
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
refactor: flatten fork logic in notifyNewPayload #7385
base: unstable
Are you sure you want to change the base?
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## unstable #7385 +/- ##
============================================
- Coverage 48.62% 48.44% -0.19%
============================================
Files 603 602 -1
Lines 40510 40407 -103
Branches 2071 2069 -2
============================================
- Hits 19700 19577 -123
- Misses 20772 20792 +20
Partials 38 38 |
Performance Report✔️ no performance regression 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.
Generally looks good, left some thoughts
serializedExecutionRequests, | ||
], | ||
method, | ||
params: generateSerializedNewPayloadParams(fork, method, {executionPayload}), |
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.
while this looks much cleaner here, we lose a lot of type safety
eg. it's possible to call it like this without complaints
params: generateSerializedNewPayloadParams(fork, method, {}),
and then you will just notice this at runtime
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 am bit unsure about this, it adds more layers of indirection and a lot more boilerplate code.
While the nested if-statements are not sustainable forever, I think right now it's not that bad.
But curious what others think
@@ -82,6 +85,22 @@ export type EngineApiRpcParamTypes = { | |||
engine_getBlobsV1: [DATA[]]; | |||
}; | |||
|
|||
// Can extend keys to other engine API whenever it sees fit | |||
export type EngineApiParamTypes = { |
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.
so while this type now makes the function call type safe it still offers the possibility that the type is not updated correctly, I was playing around with this locally and though to myself adding another type is not acceptable
How about we revert back to b29d470 and break down the |
The way the current
notifyNewPayload
is structured does not allow new fork and payload method (eg. focil fork andengine_newPayloadV5
) to be added easily without introducing more nested if statement.This PR flattens the logic into a single layer by having a switch statement which makes new methods to be added easily.