fix: genesis: feature-gated vote state #9467
Conversation
|
The Firedancer team maintains a line-for-line reimplementation of the |
There was a problem hiding this comment.
Here I dropped helpers that were sparingly used to avoid any confusion if someone was to activate/deactivate the vote state v4 feature, but they already were vended a vote account for their validator.
|
|
||
| genesis_config | ||
| #[allow(clippy::too_many_arguments)] | ||
| pub fn create_genesis_config_with_leader_ex( |
There was a problem hiding this comment.
Functionally equivalent to its original.
| } else if feature_set.inactive().contains(feature) { | ||
| // Continue silently if the user provided a feature ID twice. |
There was a problem hiding this comment.
This is a small fix to repair a "not a warning" scenario that I noticed while implementing this fix.
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #9467 +/- ##
=======================================
Coverage 82.6% 82.6%
=======================================
Files 893 893
Lines 321477 321552 +75
=======================================
+ Hits 265610 265674 +64
- Misses 55867 55878 +11 🚀 New features to boost your workflow:
|
runtime/src/genesis_utils.rs
Outdated
| do_activate_all_features::<true>(genesis_config); | ||
| } | ||
|
|
||
| pub fn activate_all_features(genesis_config: &mut GenesisConfig) { |
There was a problem hiding this comment.
i do think we want to keep alpenglow out of this for now.
I see a lot of our testing code uses activate_all_features, and not sure if this is used elsewhere. I would hate for Alpenglow to be active while it's not complete and cause problems.
There was a problem hiding this comment.
Ok sure, added a commit for this but I renamed the function.
|
If this PR represents a change to the public RPC API:
Thank you for keeping the RPC clients in sync with the server API @buffalojoec. |
AshwinSekar
left a comment
AshwinSekar
left a comment
There was a problem hiding this comment.
LGTM, cc @t-nelson for approval since I believe we want to backport this to 3.1
|
Backports to the beta branch are to be avoided unless absolutely necessary for fixing bugs, security issues, and perf regressions. Changes intended for backport should be structured such that a minimum effective diff can be committed separately from any refactoring, plumbing, cleanup, etc that are not strictly necessary to achieve the goal. Any of the latter should go only into master and ride the normal stabilization schedule. Exceptions include CI/metrics changes, CLI improvements and documentation updates on a case by case basis. |
3 participants
Problem
As described in #9377, development clusters who deactivate the vote state v4 feature are stalling since the genesis config will create vote state v4 accounts anyway.
Unfortunately, the pattern for declaring which features should be activated or deactivated when working with a genesis config is sporadic and needs refactor in order to tie it to vote state.
Summary of Changes
Unifies the feature (de)activation in genesis configs by requiring a
FeatureSetparameter for all API methods save for the one dubbed_no_features. Then, inside of the private core function, conditionally use a v3 or v4 vote account based on thevote_state_v4feature.Also updates callsites and renames the v3 vote account creator.
Fixes #9377