• Skip UnexpectedRootClaim failures #13428 👈 (View in Graphite)
• Fix tests on forked networks #13424
• Introduce forked upgrade testing #13323 : 2 other dependent PRs (#13375 , #13471 )
• develop

This stack of pull requests is managed by Graphite. Learn more about stacking.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.28%. Comparing base (c9203b0) to head (98c86a8).
Report is 7 commits behind head on upgrade-against-registry.

@@                      Coverage Diff                      @@
##           upgrade-against-registry   #13428       +/-   ##
=============================================================
+ Coverage                     47.29%   89.28%   +41.98%     
=============================================================
  Files                           943      111      -832     
  Lines                         78827     4758    -74069     
  Branches                        803      803               
=============================================================
- Hits                          37283     4248    -33035     
+ Misses                        38792      468    -38324     
+ Partials                       2752       42     -2710     

These tests are failing likely at least because the dispute game tests assume the AnchorStateRegistry is empty, so they create games that claim a low L2 block number.

There's this check in the FDG that asserts the most recent L2 block number anchor precedes the L2 block number that's claimed by dispute games -

I gather that the upgrade script loads live contracts from the superchain-registry. So the anchored block number read from the op-mainnet AnchorStateRegistry at the fork block state will be much higher than the L2 block number used to create dispute games in the test. Hence the revert on L304.

We can fix this problem by tweaking the tests to use inspect the AnchorStateRegistry to determine the L2 block numbers to use for game creation.

@Inphi that's helpful thank you!

Unfortunately, while it does help me get past that error in setUp(), it reveals a much wider range of issues that will need to be debugged. For now I think it's best to stick to the plan to revisit these tests in #13411