fix(feature-activation): fix get ancestor #930
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
I noticed there was a bug in the
_get_ancestor_at_height()
method of Feature Activation. It receives a block and an ancestor height, and returns the ancestor block with that height. In current code, it checks whether the block is voided, and if it's not, it's in the best blockchain, so we can use the height index. Otherwise, it would iterate over all parents usingblock.get_block_parent()
, which is less performatic than using the index.The issue is that this method may be called before the consensus runs for this block. This means that we do not know if the block is part of the best blockchain, and checking
not meta.voided_by
is wrong. This PR fixes this issue simply by forwarding the existing rule to the first parent block, which is guaranteed to have gone through the consensus already.This indicates that it would be beneficial to refactor metadata in a way that this bug would not be possible. We shouldn't be able to check
meta.voided_by
for a vertex that hasn't been through the consensus. We should have different metadata types depending on the state of the vertex.Note: Even if the loop ends up running, which happens only once for each Evaluation Interval (1 week) and only if the block is not in the best chain, it's not that slow. I've tested it informally inside a running local testnet node, with
20160
iterations (the maximum possible):Acceptance Criteria
_get_ancestor_at_height()
method so it gets the ancestor from the first parent block, instead of from the block itself._get_ancestor_iteratively()
function to a method to add an assertion.Checklist
master
, confirm this code is production-ready and can be included in future releases as soon as it gets merged