Arbitrum Fork and running scripts containing vm.start/stopBroadcast in test results in failing deployment

[0xCalibur]

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 (e9f274d 2022-12-11T00:03:42.968584731Z)

What command(s) is the bug in?

forge test -vvvv

Operating System

Linux

Describe the bug

There seems to be an issue with the vm.start/stopBroadcast instructions used within tests. Removing the fork and select instruction and/or the vm.start/stopBroadcast doesn't produce the issue.

Step to reproduce:

• https://github.com/0xCalibur/foundry_arbitrum_fork_issue
• forge test -vvvv

Expectation:

• test passing

What is actually happening:

➜  hello_foundry git:(main) forge test -vvvv
[⠊] Compiling...
[⠒] Compiling 2 files with 0.8.16
[⠑] Solc 0.8.16 finished in 421.27ms
Compiler run successful
2022-12-11T13:47:21.014261Z ERROR forge::runner: setUp failed reason="EvmError: Revert" contract=0x7fa9385be102ac3eac297483dd6233d62b3e1496

Running 1 test for test/Test.t.sol:CounterTest
[FAIL. Reason: Setup failed: EvmError: Revert] setUp() (gas: 0)
Traces:
  [0] CounterTest::setUp()
    ├─ [0] VM::createSelectFork(https://1rpc.io/arb, 44679129)
    │   └─ ← 0
    ├─ [1851178] → new MyScript@0x5615dEB798BB3E4dFa0139dFa1b3D433Cc23b72f
    │   ├─ [0] VM::rpcUrlStructs() [staticcall]
    │   │   └─ ← []
    │   └─ ← 1841 bytes of code
    ├─ [8937393460516792307] MyScript::run()
    │   ├─ [0] VM::startBroadcast()
    │   │   └─ ← ()
    │   ├─ [241300] → new ProxyOracle@0x5b73C5498c1E3b4dbA84de0F1833c4a029d90519
    │   │   └─ ← 1094 bytes of code
    │   ├─ [8937393460514904257] → new <Unknown>@0x104fBc016F4bb334D775a19E8A6510109AC63E00
    │   │   └─ ← 0 bytes of code
    │   └─ ← "EvmError: Revert"
    └─ ← ()

Test result: FAILED. 0 passed; 1 failed; finished in 446.87ms

Failing tests:
Encountered 1 failing test in test/Test.t.sol:CounterTest
[FAIL. Reason: Setup failed: EvmError: Revert] setUp() (gas: 0)

[joshieDo]

As a quick fix you can add --sender 0x.... to your command or call vm.startBroadcast(0x... with a specific address.

But the underlying issue seems slightly trickier.

The default foundry sender is creating the TestContract with nonce 1 resulting in the following address: 0x7FA9385bE102ac3EAc297483Dd6233D62b3e1496.

Eventually, MyScript.run() is called after changing to a fork. This change resets the default foundry sender nonce to 0. It creates the first contract (0x5b73C5498c1E3b4dbA84de0F1833c4a029d90519), and when it tries to create the second contract with nonce 1 it will try to create a contract @ 0x7FA9385bE102ac3EAc297483Dd6233D62b3e1496... which is already taken by the TestContract. I'm not entirely sure why the log is showing 0x104..., but I've debugged it and havae seen it happen.

[0xCalibur]

@joshieDo thanks for looking in to it. As another workaround within my test I have a testing boolean and just skip the broadcasts when it's true. But interesting problem here, just wondering why this specifically happen with Arbitrum forks only.

Another possible linked issue, is when deploying multiple contracts in script for Arbitrum, it seems to cause problem with gas estimation. So I need to deploy the contracts one by one. Maybe that's completely unrelated thought, just wanted to point it out.

[0xCalibur]

after this PR merge, I just ran foundryup, I assumed it will install the latest from master, right?

version is

forge 0.2.0 (e9f274d 2022-12-13T00:04:05.364169121Z)

but, I'm still having the issue presented at https://github.com/0xCalibur/foundry_arbitrum_fork_issue

[joshieDo]

after this PR merge, I just ran foundryup, I assumed it will install the latest from master, right?

@0xCalibur No, it installs the one built by the nightly pipeline.

I'm not sure if when you tried, it had already been built with the fix... so can you try again? (I did, and it worked fine).

[0xCalibur]

I confirm this is now working, I must have ran foundryup before the build was ready. Thanks.