When testing against a fork, vm.roll does not change RPC query block

[mds1]

Component

Forge

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

• Foundry
• Foundryup

What version of Foundry are you on?

forge 0.1.0 (0f58c52 2022-03-14T00:11:43.939930+00:00)

What command(s) is the bug in?

forge test --fork-url --fork-block-number <fork_block_number>

Operating System

macOS (amd)

Describe the bug

Steps to reproduce:

1. Run forge test --fork-url <url> --fork-block-number <fork_block_number>
2. block.number will return the current fork block, block.timestamp will return the corresponding timestamp, and all state read from the RPC's state at that block
3. Call vm.roll(fork_block_number + x), where fork_block_number + x is a block that has already been mined on the specified RPC
4. block.number returns the new block number, but block.timestamp and all state read from the RPC's state still give values for fork_block_number, and not fork_block_number + x

A sample use case here is testing a Uniswap TWAP oracle: scaffolding everything locally is a hassle, and it would be much easier to test prices/behavior against historical mainnet data. However, it seems this is not current possible with forge

When rolling to a block number that has not yet been mined on the provided RPC, block.timestamp can be either the same as the most recent blocks timestamp, or extrapolated by assuming a 12 second block time. Similarly, RPC queries for state should use the most recent block at the time of the roll

[onbjerg]

Can we get a link from #876? 🙏

[mds1]

Ah yes good call, done!

[onbjerg]

Hmm, thinking about this more, I wonder if this is expected behavior or not. I can see use cases for both behaviors, so it might make sense to gate one of them behind a flag?

[mds1]

Yea I was thinking about that too, I agree a flag is the right approach. Keeping the default of not changing RPC queries on roll and adding this functionality behind a flag seems reasonable to me

[onbjerg]

Relaying here from #876: a better way is to have a flag in cheats.roll, e.g. two variants:

• cheats.roll(number): Rolls our test backend to number
• cheats.roll(number, remote): Also fetches state for number for this test if remote is true

[onbjerg]

Marking this as fixed by #1715 although with a few changes (I think it doesn't use vm.roll but instead a new cheatcode?)