[ETCM-987] Fix saving the best block number without adding a mapping between block number and block hash#1090
Conversation
leo-bogastry
force-pushed
the
bugfix/ETCM-987-fix-latest-block-not-found
branch
from
90f603a to
844b1ae
Compare
…between block number and block hash
leo-bogastry
force-pushed
the
bugfix/ETCM-987-fix-latest-block-not-found
branch
from
844b1ae to
1bd58c4
Compare
leo-bogastry
requested review from
AnastasiiaL,
AurelienRichez,
jvdp and
strauss-m
jvdp
left a comment
jvdp
left a comment
There was a problem hiding this comment.
I don't disagree with this change but I feel the main improvement it does is mention the TODO in the code that this logic needs to move to a blockchain-storage related component. It won't affect the actual bug because that doesn't have much to do with fast sync, as discussed.
I think you are probably right. The modification shows that is was not just about having cache and storage in synchronization, different storages should also be always syncronized |
4 participants
Description
Calling
appStateStorage.putBestBlockNumberthat makes an update to the best block number without callingblockNumberMappingStorage.putto add the mapping between the block number and block hash can result on aNonewhen callingblockchain.getBestBlock.I wanted to add these two calls together in the blockchain or blockchainwriter class, but it is not that straight forward.
In order to be able to test this modification already I applied the fix in FastSync and created ETCM-1089 for a proper refactor
Testing
This has been tested against mainnet.