bug(anvil): anvil_dumpState is non-deterministic again

[KholdStare]

Component

Forge

Have you ensured that all of these are up to date?

• Foundry
• Foundryup

What version of Foundry are you on?

forge 0.2.0 (6b07c77 2024-12-17T16:21:09.880972720Z)

What command(s) is the bug in?

anvil

Operating System

Linux

Describe the bug

anvil_dumpState should be deterministic. In particular, running anvil_dumpState on the same anvil state should result in the same output. This is very important to us, as we rely on dumpState in CI to verify that what we are testing is the same thing that is deployed. If it's not deterministic, then we cannot rely on this check, and could inadvertently start running our tests on slightly different code than what we deployed. This does not fill me with confidence.

There is a long history of this popping back up. I first reported a variation of this 2 years ago here: #3891

To reproduce, see this repo: https://github.com/KholdStare/foundry-dumpstate-bug. In particular this script to reproduce after forge init: https://github.com/KholdStare/foundry-dumpstate-bug/blob/main/run_dumpstate.sh

My main hope from this bug is to have some basic unittests established that will catch regressions in this. This has cropped up numerous times, and each time the issue is fixed but no unittest is added to catch non-determinism in anvil_dumpState. Some tests to try:

• blank anvil state should produce the same anvil_dumpState every time
• deploying something should produce the same anvil_dumpState every time
• round trip test. anvil_dumpState -> anvil_loadState -> anvil_dumpState should produce the same output

[mattsse]

what regression have you observed besides the output being different?
which can be explained by different gzip output due to different ordering and thinks like different timestamp of the first block

[KholdStare]

We upgrade foundry only when we release a new version of our contracts. Last time we updated was a year ago, when anvil_dumpState was deterministic (https://github.com/foundry-rs/foundry/releases/tag/nightly-5b7e4cb3c882b28f3c32ba580de27ce7381f415a).

The regression is that the output is different. We were relying on the output being the same.

Our setup:

• We have some integration tests in typescript that load up a "golden" starting state in anvil before every test. We check this golden state into git as a reference, and also to avoid rebuilding it when the team is not touching the contracts. The golden state is what is currently deployed.
• We have CI checks to ensure that the source contracts/deployment that is checked in, matches what is in the saved golden state. If they differ, something changed. (e.g. this could be an unintended contract change, could be different optimization setting, could be new foundry bug, who knows) This sanity check is important because we can confidently say the tests are checking the exact same thing that was deployed.

IMHO, anvil_dumpState being completely opaque without any determinism really hurts its utility.

Regarding the block timestamp - to make sure that's not the only source of non-determinism, is there any way to guarantee block timestamps when anvil mines them?