fix(anvil): respect configured genesis number when restoring genesis_hash#14488
Open
AissataF wants to merge 2 commits intofoundry-rs:masterfrom
Open
fix(anvil): respect configured genesis number when restoring genesis_hash#14488AissataF wants to merge 2 commits intofoundry-rs:masterfrom
genesis_hash#14488AissataF wants to merge 2 commits intofoundry-rs:masterfrom
Conversation
…_hash` `BlockchainStorage::load_blocks` was hardcoding `block_number == 0` to detect the genesis block during state-snapshot restore, so a non-zero genesis (e.g. `--block-number 73 --load-state ...`) left `genesis_hash` pointing at the dummy block created in `new()`. Store `genesis_number` on `BlockchainStorage` and compare against it, so `Earliest`/`Safe`/`Finalized` tag lookups return the actual restored hash. Extends the partial fix from foundry-rs#12645.
AissataF
requested review from
0xrusowsky,
DaniPopes,
figtracer,
grandizzy,
mablr,
mattsse,
onbjerg,
stevencartavia and
zerosnacks
as code owners
Regression test for the fix in 3a7634f: when `BlockchainStorage` is configured with a non-zero `genesis_number` (e.g. `--block-number 73 --load-state ...`), `load_blocks` must rewrite `genesis_hash` to the loaded block matching `genesis_number` instead of the hardcoded block 0.
AissataF
force-pushed
the
fix-load-blocks-block
branch
from
62c78b2 to
52e84b6
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
BlockchainStorage::load_blockswas hardcodingblock_number == 0to detect the genesis block during state-snapshot restore. With--block-number 73 --load-state ..., no loaded block matched, sogenesis_hashkept pointing at the dummy block fromBlockchainStorage::new()andEarliest/Safe/Finalizedtag lookups returned the wrong hash.Stored
genesis_numberonBlockchainStorageand compare against it inload_blocksinstead. All existing constructors (new,forked,empty) wire the new field through.the meaningful diff in
load_blocksis one line —block_number == 0becomesblock_number == self.genesis_number. The follow-up commit adds a regression test that setsgenesis_number = 73, loads a serialized block at 73, and assertsgenesis_hashis rewritten to the loaded hash. There is also a sanity case proving that withgenesis_number = 0and no block 0 in the snapshot, the dummygenesis_hashis preserved— i.e. the new test would have failed under the old hardcoded
== 0logic