eth_subscribe timeout on mainnet

[PierreJeanjacquot]

Hi,

I'm using web3js in Nodejs to watch events from a smart contract on mainnet. For some reason, sometimes the subscription fail.

Under the hood, web3 call eth_subscribe to register to the logs but sometimes the rpc call timeout.

[
  'logs',
  {
    topics: [
      '0xce0457fe73731f824cc272376169235128c118b49d344817417c6d108d155e82'
    ],
    fromBlock: 'latest',
    address: '0x314159265dD8dbb310642f98f50C066173C1259b'
  }
]

I have the same problem on different contracts on mainnet, here is a code example to reproduce:

const Web3 = require('web3');

const abi = [
  {
    anonymous: false,
    inputs: [
      { indexed: true, name: 'node', type: 'bytes32' },
      { indexed: true, name: 'label', type: 'bytes32' },
      { indexed: false, name: 'owner', type: 'address' },
    ],
    name: 'NewOwner',
    type: 'event',
  },
];

const openWS = (wsHost) => {
  const provider = new Web3.providers.WebsocketProvider(wsHost, {
    timeout: 10000,
  });
  const web3 = new Web3(provider);

  const contract = new web3.eth.Contract(
    abi,
    '0x314159265dD8dbb310642f98f50C066173C1259b',
  );

  contract.events.NewOwner({}, (err, event) => {
    console.log('err', err);
    console.log('event', event);
  });
};

openWS('wss://mainnet.infura.io/ws/v3/myapikey');

I don't have this problem with Kovan network (Parity) or on a local mainnet Parity node, it may be related to Geth but I don't have a local Geth node to test...

[ryanschneider]

Hi Pierre, we just this morning pushed some improvements to our logs subscription backend, let me know if you continue to see any issues.

The underlaying issue is, as you suspected related to stability w/ geth and lots of subscriptions. We try to "virtualize" subscriptions and run them off our own systems instead of directly on ethereum nodes, but due to some load related issues recently we had to fall back to servicing some subscriptions directly via backend ethereum clients. We're hoping this latest round of improvements will allow us to keep all log subscriptions 100% virtualized.

Also note that your websocket connection will be disconnected after one hour of inactivity, which can happen if your filter leads to very rare updates. As such we suggest you either periodically send us RPCs (e.g. eth_blockNumber) or keep a "newHeads" subscription active as that gets frequent updates with every block so will keep the connection active.

[PierreJeanjacquot]

Hi Ryan, thank you for your quick answer. Stability seems to be much better today :+1: I will keep you informed if the issue appears again. About inactive socket disconnection, I already use RPC call to keep the socket alive, no problem on this side :)