Fix(store-sync): Handle unsynced RPC nodes

Context: https://indexsupply.com/shovel/docs/#unsynchronized-ethereum-nodes

3rd party Ethereum API providers may load balance RPC requests across a set of unsynchronized nodes. In rare cases, the eth_getLogs request will be routed to a node that doesn’t have the latest block.
This issue has been noticed multiple times on Redstone

Solution: Batch fetch the latest block number with the logs, and ensure that the latest block number is past the toBlock. Otherwise, wait for the RPC to catch up to the latest block.

This fix relies on the client making a batch call to the RPC, which needs to be enabled by clients in their Viem HTTP transport.

For the sync stack, the fromBlock is decided from a local variable and the toBlock is decided by a subscription to the latest block number. So we need an additional filter from the latest block number subscription to not emit when the toBlock is behind the fromBlock, which happens with unsynchronized RPCs.

There is currently silent failure when this happens as when toBlock is less than fromBlock, no error is thrown, and no logs are fetched either, as this while loop will resolve false. So in this PR, we add a filter to not emit incorrect toBlock's and also a safety error check to throw if this case occurs.
- Because the batch call actually seems like only a fix for HTTP, I think this is the real issue that's causing incorrect logs with the sync-stack (since the default is to use WS). This is in-line with what we're seeing on the logs of the Biomes indexer pod, where it doesn't show there are 0 logs, but that the storageAdapter is never called.

latticexyz / mud

Fix(store-sync): Handle unsynced RPC nodes #2901

⚠️ No Changeset found