local_filter_middleware is different from geth filter when to_block is specified

[yiteng-guo]

What was wrong?

# local filter
fltr = w3.eth.filter(
{
    "fromBlock": 14231060,
    "toBlock": 14231065,
})
fltr.get_new_entries() # Return [], assuming current block number 14231070
fltr.get_new_entries() # Return [logs between block number 14231070 and 14231072], assuming current block number 14231072

# geth filter
fltr = w3.eth.filter(
{
    "fromBlock": 14231060,
    "toBlock": 14231065,
})
fltr.get_new_entries() # Return [], assuming current block number 14231070
fltr.get_new_entries() # Return [], assuming current block number 14231072

Okay, I have to say this is very confusing. The local middleware output is different from geth and both of them are counter-intuitive IMO. I think the most intuitive output should be

fltr.get_new_entries() # Return  [logs between block number 14231060 and 14231065], assuming current block number 14231070
fltr.get_new_entries() # Return [], assuming current block number 14231072

but geth doesn't think so. I guess web3.py should probably just follow what geth does for the sake of consistency.

How can it be fixed?

The fix is very simple. We just need to add continue here https://github.com/ethereum/web3.py/blob/master/web3/middleware/filter.py#L155.

[kclowes]

The block numbers don't make sense in your example. Can you update your comment to reflect the block numbers you're thinking of? If the current number is 14231040, you should not get any logs when you're looking for blocks between 14231060 and 14231065.

[yiteng-guo]

Sry, the current block number should be 14231070. I've modified the issue above.

[yiteng-guo]

Any update on this?