You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix: toBlock argument in L1 getLogs is inclusive (#10828)
As @alexghr identified, we got a spurious reorg on a node in the exp1
network. This was caused by the node getting a current
`l1BlockNumber=245`, but then fetching an L2 block mined at 246.
This caused the `canPrune` check to fail:
```
const canPrune =
localPendingBlockNumber > provenBlockNumber &&
(await this.rollup.read.canPruneAtTime([time], { blockNumber: currentL1BlockNumber }));
```
The `canPruneAtTime` was evaluated at L1 block number 245, and it
correctly returned true, since there had been a reorg shortly before (at
240), and no new L2 block had been mined so the rollup hadn't reset its
state by then. However, the `localPendingBlockNumber` was incorrectly
increased due to the block mined at 246, which caused the archiver to
incorrectly reorg it.
This PR fixes the L1 event queries so the `toBlock` is inclusive. A
quick test with cast shows that this is the case:
```
$ cast logs -r https://mainnet.infura.io/v3/$INFURA_API_KEY --from-block 0x146eade --to-block 0x146eadf --address 0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48 --json | jq .[].blockNumber | uniq
"0x146eade"
"0x146eadf"
```
And just for good measure, we also filter the logs returned by the block
range searched.
0 commit comments