-
-
Notifications
You must be signed in to change notification settings - Fork 331
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
Add feerecipient and gas_limit routes #4511
Conversation
d281210
to
38d5150
Compare
Performance Report✔️ no performance regression detected Full benchmark results
|
@@ -152,6 +161,12 @@ export const validatorOptions: ICliCommandOptions<IValidatorCliArgs> = { | |||
type: "string", | |||
}, | |||
|
|||
flushKeymanagerProposerConfigs: { | |||
description: "If keymanager's persisted proposer configs are found, delete them all!", |
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.
This is a very strange flag, is this really necessary?
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.
this to to clear keymanager proposer configs, although name can be better 🙂 , any suggestions?
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.
What's the usecase? There's the delete API for that right?
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.
the use case is you used keymanager api to make proposer data updates, and now want to discard it and switch to proposerFileConfig. Since now proposerFileConfig
flag will error since we don't accept proposerFileConfig
if there is keymanager persisted proposer data, this flag can be used to discard and clean keymanagaer persisted configs.
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.
removed the flag! and recommended manual deletion in case of conflict 👍
builder.enabled !== undefined || | ||
builder.gasLimit !== undefined | ||
) { | ||
proposerConfig = {graffiti, strictFeeRecipientCheck, feeRecipient, builder}; |
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.
Does the ValidatorStore really need to know about the idea of a proposerConfig? Feels like it's the API role to construct this object from the other methods
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.
ummm i don't find the idea of ValidatorStore knowing about the proposer config odd as we also pass proposer data in the addSigner now.
Other getters anyway return defaults if the that particular property is not assigned.
valProposerConfig = parseProposerConfig(args.proposerSettingsFile, defaultConfig); | ||
} else { | ||
valProposerConfig = {defaultConfig} as ValidatorProposerConfig; | ||
} |
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.
Consider moving to a function below the handler getValProposerConfig(args): ValidatorProposerConfig
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.
you mean separate out this parseProposerConfig section from getProposerConfigFromArgs
?
7d4b097
to
908f13f
Compare
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.
Looks good thanks for those sweet e2e tests ❤️
Some comments that are addressable post merge:
- Should builder.enabled and builder.gasLimit be flattened in ProposerConfig?
- The logic of getProposerConfig says that if some property is set everything else won't be applied defaults. Is that expected behaviour? This function is only used in the API but not in the validator store to perform duties right?
ummm actually, i should rename Else, individual gets of I like your idea idea on flattening the builder params 👍 , how about |
Add feerecipient and gas_limit routes
Passes the oapi spec test checker locally (since the opai release json is not available, constructed it locally, have asked for an alpha release on keymanager api so the api spec tests check can be enabled)

Closes #4392 Closes #4393
TODO:
- [ ] Enable oapi spec tests (once the keymanager alpha release is done making the json asset avaiilable to be fetched)can be followed up in a separate PR as not show stopperproposerSettingsFile
providedproposerSettingsFile
if there is proposer data saved in the keymanagar proposer dir unless provided with a flush flag:--flushKeymanagerProposerConfigs
in which case the directory is deleted at startup