George Knee
George Knee
Similar tests exist in an unmerged PR here https://github.com/ethereum-optimism/optimism/pull/17751/files#diff-58dd5c61df58d9692977d4999df0077508b5575933bfe4e81c50a217bcdbe3ddR14 and here https://github.com/ethereum-optimism/optimism/pull/17751/files#diff-58dd5c61df58d9692977d4999df0077508b5575933bfe4e81c50a217bcdbe3ddR59
Conversation with @sebastianst today. It seems that when the chain is "healthy" (sequencing window not expired), but the sequencer is in recover mode, the sequencer will request an l1 origin...
I still haven't figured out why the temporary error returned by the current implementation doesn't eventually go away when that next l1 block becomes available. It is true that an...
Possibly relevant PR https://github.com/ethereum-optimism/optimism/pull/18233
/ci authorize [62490c8](https://github.com/ethereum-optimism/optimism/pull/18534/commits/62490c8f7b610ebdc13e2e69203afe86d7be6de8)
Prior art here may be all we need https://github.com/flashbots/contender
@sebastianst do you think if we implement https://github.com/ethereum-optimism/optimism/issues/12124 it might just handle this case?
Answering my own question -- experimenting with #12430 I realise that that feature will have some inherent delay or lag (at least a few L1 block times). This might be...
This ticket can be closed because the batcher already checks for expected progress, so would detect a channel which straddles activation and recover from it. We will try to confirm...
> I've looked into this and it seems like changes are needed in around 5 Go files. Can I take this? Sure thing!