Fix bug parent hash on BlockV2
upgrade
#570
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.
This bug can be reproduced after storage upgrade from
BlockV0
toBlockV2
, and only if the preceding block contained transactions. In that case thecurrent_block_hash
function will try to decodeBlockV2
, failing to do so because the block containsTransactionV0
s and returningNone
, defaulting toH256::default()
, rendering the parent hash useless and of course messing the block hashing of the subsequent blocks.This PR proposes just use the already existing
BlockHash
storage and query it using the previous block number.This is a pretty nasty bug and should merged in asap @sorpaas . Also, do you have any suggestion on how to test this type of situation in frontier?