-
Notifications
You must be signed in to change notification settings - Fork 682
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
Pull apart writeCurrentStakers method - Part 3 #2086
Pull apart writeCurrentStakers method - Part 3 #2086
Conversation
…current_stakers_testable_3
…current_stakers_testable_3
…current_stakers_testable_3
…current_stakers_testable_3
…current_stakers_testable_3
…current_stakers_testable_3
// nothing to do | ||
} | ||
|
||
addedDelegatorIterator := NewTreeIterator(validatorDiff.addedDelegators) |
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.
(No action required) Why do addedDelegators use an iterator but deletedDelegators do not?
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 has to do with the way we have built iteration over stakers in diffs. Delegators added must be iterated in order hence are stored in a tree; deleted delegators must only be queried and skipped.
status: added, | ||
staker: validatorDiff.validator, | ||
}) | ||
|
||
outputWeights[key].Amount = weight | ||
if blkKey != nil { | ||
// Record that the public key for the validator is being |
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.
(No action required) Why is the variable named outputBlsKey
if it storing the 'prior value for the public key'?
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.
outputBlksKey will be used to store bls key diffs. Naming is in analogy with outputWeights
vms/platformvm/state/state.go
Outdated
outputValSet[key] = validatorStatusPair{ | ||
validator: validatorDiff.validator, | ||
status: validatorDiff.validatorStatus, | ||
outputValSet[key] = stakerStatusPair{ |
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.
(No action required) Where possible, consider avoiding mixing non-functional (e.g. naming) changes with functional ones.
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 tried to be descriptive with the struct name. stakerStatusPair
used hold validators data only, while in this PR it is extended to hold delegators data too. Seems fit to rename the struct
addedDelegatorIterator := NewTreeIterator(validatorDiff.addedDelegators) | ||
defer addedDelegatorIterator.Release() | ||
for addedDelegatorIterator.Next() { | ||
output = append(output, stakerStatusPair{ |
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.
Is addition/deletion of a given delegator dependent on the state of their validator?
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.
not at state level. When accepting transactions created delegators, validations enforces that delegators delegate to an existent validator.
Is this strictly a refactor for readability, or is testability also an eventual concern? |
…current_stakers_testable_3
…current_stakers_testable_3
I'd say it's for readability. I am not sure we should unit test these low level changes. I see them as implementation and if we change it, we'd have to change the test too. |
7ad8fd5
to
83c661c
Compare
…current_stakers_testable_3
…current_stakers_testable_3
…current_stakers_testable_3
…current_stakers_testable_3
…current_stakers_testable_3
…current_stakers_testable_3
…current_stakers_testable_3
…current_stakers_testable_3
…current_stakers_testable_3
…current_stakers_testable_3
…current_stakers_testable_3
…current_stakers_testable_3
…current_stakers_testable_3
…current_stakers_testable_3
…current_stakers_testable_3
…current_stakers_testable_3
…current_stakers_testable_3
…current_stakers_testable_3
…current_stakers_testable_3
…current_stakers_testable_3
…current_stakers_testable_3
…current_stakers_testable_3
…current_stakers_testable_3
…current_stakers_testable_3
…current_stakers_testable_3
Closing down since there is no agreement this is a simpler solution than existing one |
Why this should be merged
writeCurrentStaker
is a bulky method in platformvm state package that process stakers diffs and store them.Cleanup list:
How this works
writeCurrentStaker
is broken into two main parts:How this was tested
CI