-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
fix(anvil
): reset from fork to another fork
#8768
Conversation
anvil
): reset from fork to another fork
// reset storage | ||
*self.blockchain.storage.write() = BlockchainStorage::forked( | ||
fork.block_number(), | ||
fork.block_hash(), | ||
fork.total_difficulty(), | ||
); | ||
self.states.write().clear(); | ||
self.db.write().await.clear(); | ||
// self.db.write().await.clear(); |
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.
why do we no longer need this?
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.
Correct me if I'm wrong but we no longer need this because when we reset to a new forked state from a non-fork/old-fork state, we use self.db
(Backend.db
) as an intermediate step to set the database
in ClientFork
, here and here.
So even when we clear - self.db.write().await.clear();
, RPC calls work because they refer to the database in the fork + foundry_fork_db::SharedBackend
.
hey @yash-atreya, wonder if you got the chance to test it with arbitrum forks too, there's a special case with block L1/L2 Not sure if it needs to be addressed here too but think it worth flagging foundry/crates/anvil/src/eth/backend/mem/mod.rs Lines 1734 to 1746 in d127137
|
fix: temporarily disable dry-run in cli-advanced-e2e - until we fix the problem with our call to `resetFork` after a dry-run deployment - our CI uses the latest nightly foundry releases, and this recent PR foundry-rs/foundry#8768 has broken the fork reset. Ironically, this PR actually is a bugfix for something that was broken that we relied on. Examples of failures: - https://github.com/hyperlane-xyz/hyperlane-monorepo/actions/runs/10772795435/job/29873480020?pr=4441#step:12:133 - https://github.com/hyperlane-xyz/hyperlane-monorepo/actions/runs/10751285630/job/29818541086?pr=4448 Note that the `pi_with_core_chain` tests don't fail because they do not do a dry run
Motivation
Fixes #8684
Resetting from an existing fork to another fork would not update underlying
ForkedDatabase
, resulting in an invalid state for the new fork.Solution
reset the underlying the
ForkedDatabase
usingnode_config.setup_fork_db_and_config