[Testing] Test multi-mode L1

[frisitano]

Overview

In #409, we introduced a mechanism that allows for events from L1 to be consumed eagerly. This is to say that messages will be consumed before they are finalized and we will react to reorgs on L1 if they are to occur. We need to add more comprehensive testing to cover the following cases:

• Correct behaviour when consuming events from L1:

Event	Sync State	Expected Outcome
BatchCommit	Syncing	There should be no change as we only trigger batch commit events when the BatchFinalized event has been finalized on L1
BatchCommit	Synced	There should be an update to the safe head of the node
BatchFinalized	Syncing	This should trigger all unprocessed BatchCommit events up to the finalized batch (the BatchFinalized event must be finalized on L1). This should update both the safe and finalized head to the latest block in the last BatchCommit event
BatchedFinalized	Synced	This should update the finalized head (the BatchFinalized event must be finalized on L1
BatchRevert	Syncing	This should have no effect
BatchRevert	Synced	This should update the safe head to the last block of the batch commit before the reverted batch
BatchRevertRange	Syncing	This should have no effect
BatchRevetRange	Synced	This should update the safe head to the last block of the batch commit before the reverted batch range

• L1 reorg of BatchCommit, BatchFinalization, BatchCommit, and BatchRevert events. It should be noted that when the rollup-node is still actively syncing from L1, the rollup-node will wait for BatchFinalization before it processes a batch. After the rollup-node finishes historical sync, as indicated by the L1Synced event from the watcher, it will process the BatchCommit event, immediately updating the safe block number.

Reorged Event	Expected Outcome
BatchReverted	Update the safe head to the last block number associated with the reverted batch
BatchRangeReverted	Update the safe head to the last block associated with the last batch of the reverted batch range
BatchCommit	Update the safe head to the last block of the previous BatchCommit
BatchFinalized	No change because we only update the finalized head after the BatchFinalized event is finalized on L1 meaning it can never be reorged

• When a node shuts down and then starts up again, we should make sure that it can handle any reorgs that have happened whilst the node has been shut down. If we had unfinalized L1 events in the database when he node shutdown we should make sure these are reorged away on startup if a reorg occurred on L1.

Implementation

We should create batches and chains that allow us to test all the cases above. We should introduce an instance of anvil into the TestFixture introduced in #407 - anvil reference: https://github.com/foundry-rs/foundry/blob/12be76ff47ae0f4fe1a18b74a47e5f0611bab5a0/crates/anvil/src/lib.rs#L114. We should configure this anvil instance using the anvil state we use for docker-compose testing.

[jonastheis]

I think the described scenarios are complete and cover all the different good cases.

However, there might be some additional more defensive scenarios necessary especially when we eagerly process BatchCommit events. Specifically, there might be many reasons (malformed data, invalid message queue hash, invalid block numbers, etc) why a batch might be invalid (until it is eventually reverted). We should make sure that the derivation pipeline can handle those cases gracefully.

[frisitano]

However, there might be some additional more defensive scenarios necessary especially when we eagerly process BatchCommit events. Specifically, there might be many reasons (malformed data, invalid message queue hash, invalid block numbers, etc) why a batch might be invalid (until it is eventually reverted). We should make sure that the derivation pipeline can handle those cases gracefully.

Good catch. Currently, we would attempt to reprocess the batch indefinitely. We need to consider what the desired behaviour would be in the case where a batch is invalid.