web3.eth.getFilterChanges (web3_filter.filter_id) arroja 'filtro no encontrado'

Estoy escuchando la red ethereum a través del nodo geth local. Me conecté a geth a través de web3.py. Comencé un trabajo en código python que periódicamente obtiene nuevos bloques del filtro. Aquí está el código:

def main():
    web3 = Web3(HTTPProvider(cfg.eth_node_url))        
    web3_confirmed_filter = web3.eth.filter('latest')

    scheduler = BlockingScheduler()

    scheduler.add_job(
        func=eth_listener_job.process_blocks(),
        args=[web3, web3_confirmed_filter],
        trigger=IntervalTrigger(seconds=cfg.pending_trx_scan_interval),
        id='block_processor',
        name='Load new blocks',
        replace_existing=True)   

    scheduler.start()

Aquí cómo se ve el método de trabajo

def process_blocks(web3, web3_filter):
    print('Scanning for new blocks...')

    ....
    trx_blocks = web3.eth.getFilterChanges(web3_filter.filter_id)
    ....

A veces recibo un error en línea

trx_blocks = web3.eth.getFilterChanges(web3_filter.filter_id)

ValueError: {'code': -32000, 'message': 'filter not found'}

¿Cuál podría ser la razón de este error?

Respuestas (1)

Resumen

El nodo (geth) está eliminando el filtro, tal vez debido a la inactividad, por lo que regresa filter not foundpor esa ID.


¿Por qué?

De manera informal, los filtros funcionan sobre json-rpc funcionan así:

  1. Enviar al nodo: "Crear un filtro con los parámetros X, Y, Z"
  2. El nodo responde: "Filtro instalado, con ID 456"
  3. Enviar al nodo: "¿Alguna información nueva sobre el filtro ID 456?"
  4. Nodo responde: "Sí, estos cambios: [...]"
  5. El tiempo pasa...
  6. Node decide desinstalar el filtro 456
  7. Enviar al nodo: "¿Alguna información nueva sobre el filtro ID 456?"
  8. Nodo responde: "No tengo registro del filtro 456"

Desafortunadamente, la especificación no tiene mucho que decir sobre cuándo se le permite al nodo desinstalar el filtro. El nodo puede hacerlo a voluntad y sin previo aviso. Entonces, al final, lo único que puede hacer es verificar el error y volver a crear el filtro si no está... (uf, lo sé)


Planes Web3.py

Hay un problema abierto para dejar de usar ese mecanismo de filtro json-rpc por completo y mantener todo el estado del filtro en el lado web3.py. Fue inspirado exactamente por el problema que mencionaste.