How does viem handle incorrect block height from infura?

[benesjan]

Hello,
because of load balancing, the latest block number returned from Infura is sometimes higher than the block number up to which another node used by Infura was synced and this behaviour can result in ignored events if it's not accounted for. To provide a more complete example this is how it could happen:

1. I fetch latest block number from infura and the value is 10000,
2. I request all the events from from a block range 9000 - 10000,
3. I receive 0 events in a given range even though there actually was a relevant event at a block 9999 but the specific node to which the request was routed just didn't manage to sync up to 10000 yet,
4. If I am not aware of this bug I assume that there were no events in the range and I start listening for events starting at block 10001.

Am I correct to assume that if I use the watchContractEvent functionality to listen for new events the events could get skipped?

A way to workaround this is to alway be fetching events from a block range <num_of_last_block_containing_log + 1; latest_block_num> instead of <num_of_latest_block_from_last_range + 1; latest_block_num>.

Thank you

[jxom]

viem uses eth_newFilter & eth_getFilterChanges for watchContractEvent, which is mutually exclusive of latest block number. So it should work for Infura (to answer your question).

However, if the RPC Provider does not support filters, we fall back to eth_getLogs which is mutually inclusive of latest block number. We rely on the previously queried block number there, so it’ll probably be a good idea to update the fall back implementation for the case you mentioned (for RPC providers that don’t support filters and have load balancing mechanisms).