Filters: eth_newBlockFilter does not return canonical blocks

[ankitchiplunkar]

Hi there,

System information

Geth version: 1.8.17-stable-8bbe7207
OS & Version: Ubuntu 18.04

Expected behaviour

The eth_newBlockFilter when queried for using eth_getFilterChanges should return the forked blocks and also subsequently the canonical blocks.

Actual behaviour

The eth_newBlockFilter when queried for using eth_getFilterChanges does not return the canonical blocks (for almost every ~70 blocks)

Steps to reproduce the behaviour

I have a local geth node, am using web3.py for getting newblockfilters

from web3.auto import w3
from web3.utils.encoding import (to_hex)
import time

def log_loop(filter, poll_interval):
    while True:
        events = w3.eth.getFilterChanges(filter.filter_id)
        print(events)
        for event in events:
                blockData = w3.eth.getBlock(event) 
                print(("{}, {}, {} \n".format(to_hex(blockData['hash']), blockData['number'], to_hex(blockData['parentHash']))))
        time.sleep(poll_interval)

block_filter = w3.eth.filter('latest')
log_loop(block_filter, 1)

From time to time, I get a forked block from the filter but not the canonical block.

0x316c065382afdaa0a5946c168d151d5178690e94bf523571da323f5330c40363, 6630926, 0x26c2df9cf5a53e0643ea72653e9864de2c99643d26a896dbcf51bf0bd55fd186
0x82d8e543820d6a0c996a6b5eab816cae7e520ccdeec4e5478ebfb0ddbf999c9b, 6630927, 0x54d2120357ed9f9af4974b355e9d868e7aca96cb937c997f5ad870c2fe8a09e6

As we an see the hash of block 6630926 does not match the parent hash of 6630927, also the block 0x316c065382afdaa0a5946c168d151d5178690e94bf523571da323f5330c40363 does not exist in the canonical blockchain.

Is it possible to get canonical blocks from filterchanges method without relying on using the method eth_getBlockByNumber?

[jpzk]

This is an important issue, I believe many companies rely on this. It's also a major differentiator if it works in Geth, also Parity is unreliable.

[calebrate]

This is linked to #18029

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[rjl493456442]

It should be fixed, reference: #18322