Fetching for block ranges events with `eth_getLogs`

There's a common technique used by developers when scanning for smart contract logs - first, call eth_blockNumber and then used it as a toBlock argument in the eth_getLogs request. By doing this it's easy to control the block ranges that you're scanning. However, because of the lack of standard in JSON-RPC regarding how clients handle an empty vs a missing block in eth_getLogs, this could expose a bit of inconsistency around the chain head. We mimic Geth's behaviour (and many other blockchain clients for that matter), which is to return an empty list when the block is missing. So the question is: how can I be sure that I have received all the logs from that block range? Or, more accurately, how can I make sure that whatever serves my eth_getLogs request knows about the last block I've retrieved via eth_blockNumber?

There is a simple way to check if that block has logs or not by calling eth_getBlockByNumber, and then checking the returned logsBloom value. If it is 0x000000000........00000000, then that block does not have any logs. That way you'll know and you can verify the eth_getLogs response. If you were expecting logs for that last block and you have none, then the safest thing is to retry the request — it could be some delay in indexing the last block.

Of course, you could also subscribe and listen for events via WebSocket subscriptions. In that case don't forget to deal with potential disconnects on idle connections — learn more about keeping WebSocket subscriptions alive and able to reconnect on failure.