vm.roll can result in panic on L2 network

[RiccardoBiosas]

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

What command(s) is the bug in?

forge test

Operating System

Linux

Describe the bug

As described in this issue, forge does not currently handle the idiosyncrasies of each EVM-compatible L2 network. In the context of testing contracts which rely on a block.number delta against an Arbitrum fork pinned at a certain block, using vm.roll as a workaround would suffice until now.

However, after upgrading to foundry 2.0, forking an Arbitrum live network pinned at a certain block (i.e.: forge test --fork-url ARBITRUM_RPC --fork-block-number 1337) and then using vm.roll to set the test contract's block.number to an L1 value results in a panic. This prevents me from testing some logic where the L2 contract calculates the difference between a lastBlockNumber variable and the current block.number (both L1 values).

I think that the change responsible for this behavior is this commit. In fact, after downgrading foundry to the previous commit ( foundryup -C 4415ff47cc03c9f9657dd2959f57de411a4e67b2), the test/vm.roll worked again as expected

[mattsse]

thanks for raising this,

using vm.roll to set the test contract's block.number to an L1 value results in a panic.

this is the expected behavior, because the fork is bound to a specific chain.

#ceaecc660 introduced panics because that's the only safe behavior when we failed to look up data on the fork.

this is good feedback and we're working on making forking support more flexible for different L2s: #834

so you can easily switch the context from within your test and the use case you're describing should be possible.

[onbjerg]

@mattsse Is this fixed by multi-fork? If so, can you kindly link PR and issue together? 😄

[mattsse]

it's not handled automatically yet, a workaround is described here #748 (comment)

we decided to hold off on this until the major L2 upgrades are rolled out before baking in chain agnostic stuff.

but I think we can close this in favor of #748 ?

[onbjerg]

Yeah, agreed 👍