@TODO TypeError: results is not iterable at FilterIdEventSubscriber._emitResults

[hedgehog-millenium]

When i try to listen to all event on contract with code contract.on('*',handleFuction) it seems to start work correct .It's catching events and handles them as per handler function , but after some time it trows an error @TODO TypeError: results is not iterable. When i restart listener it handles the same event with no issue. After googling and going trough the code the only assumption is that connection is being closed between listener and local hardhat jsonRpcProvider , but still cant get any direct reason from the error and cant catch it manually . Keep receiving the same error . Anyone have any idea what can be the real reason and how to avoid it ?

sync function listenToEvents(contractAddress, abi, jsonRpcProviderEndpoint, db) {
    const provider = new ethers.JsonRpcProvider(jsonRpcProviderEndpoint);
    const contract = new ethers.Contract(contractAddress, abi, provider);

    console.log("listening on contract at address: ", contractAddress)

    const eventListener = async (event) => {
        try {
            console.log(`New ${event.eventName} event emitted`);
            const { data, topics, transactionHash, index } = event.log;
            const evtDecoded = parseEvent(contract, event.eventName, data, topics, transactionHash, index);

            await processEvent(db, event.eventName, evtDecoded, eventHandlers);
        } catch (error) {
            console.error('Error occurred while processing event:', error);
        }
    };

    const startListening = () => {
        contract.on('*', eventListener)
            .then(() => {
                console.log('Event listener started.');
            })
            .catch((error) => {
                console.error('Error occurred while starting event listener:', error);
                // Handle the error and attempt reconnection
                setTimeout(startListening, 5000); // Retry connection after 5 seconds
            });
    };

    startListening();

[zemse]

I believe this is due to an occasional bad result from RPC for eth_getFilterChanges request. What is your RPC provider or are you running your own node?

You can use provider.on("debug", console.log) to see RPC responses, note down the actual response from the RPC provider, and report to the RPC provider including request and result.

I think this could qualify as something ethers should handle and maybe just retry the request or at least allow the dev to catch. cc @ricmoo

Here is a quick script I used to confirm the above claim:

  const provider = new ethers.JsonRpcProvider(
    "https://eth-mainnet.g.alchemy.com/v2/<apikey>"
  );
 
  // hack into the provider to return bad value 
  let sendOriginal = provider.send;
  provider.send = async function (...args) {
    if (args[0] === "eth_getFilterChanges") {
      return null;
    }
    return await sendOriginal.bind(provider)(...args);
  };

  const erc20 = new ethers.Contract(
    "0x6b175474e89094c44da98b954eedeac495271d0f",
    ["event Transfer(address indexed from, address indexed to, uint256 value)"],
    provider
  );

  erc20.on("Transfer", (event) => {
    console.log(event);
  });

@TODO TypeError: results is not iterable
    at FilterIdEventSubscriber._emitResults (/Users/sohamzemse/Workspace/ethers/temp/node_modules/.pnpm/[email protected]/node_modules/ethers/src.ts/providers/subscriber-filterid.ts:159:30)
    at FilterIdEventSubscriber.#poll (/Users/sohamzemse/Workspace/ethers/temp/node_modules/.pnpm/[email protected]/node_modules/ethers/src.ts/providers/subscriber-filterid.ts:96:24)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)

[hedgehog-millenium]

I'm using a local hardhat node which is running in docker . Hardhat version 2.13.0

[sertony]

In our project we've fixed it by forcing the hardhat node generating new blocks, i.e.

 const config: HardhatUserConfig = {
     solidity: '0.8.20',
     networks: {
         hardhat: {
             // See: https://hardhat.org/hardhat-network/docs/reference#mining-modes
             mining: {
                 auto: true,
                 // Produce new block every 3 minutes to resolve next issues
                 // https://github.com/NomicFoundation/hardhat/issues/2053
                 // https://github.com/ethers-io/ethers.js/issues/2338
                 // https://github.com/ethers-io/ethers.js/discussions/4116
                 interval: 3 * 60 * 1000, // should be less then 5 minutes to make event subscription work
             },
         },
     },
 };

This is important since the 5 minute deadline is getting expired due to the fact that it's not renewed when reading the filter changes which happens in ethers only once a new block is generated.