WebSocket calls do not throw error after connection has closed

[proficy]

I have the following code using ethers js:

const ethers = require("ethers");

let ws = 'ws url';
let provider = new ethers.providers.WebSocketProvider(ws);

let ethersTest = async () => { 
  console.log(await provider.getBlockNumber());
  // sleep for 61 seconds. websocket is closed after 60 seconds
  await new Promise(resolve => setTimeout(resolve, 61000));
  try {
    console.log(await provider.getBlockNumber());
  }
  catch (err) {
    // this point is never reached
    console.log(err);
  }
}

ethersTest();

After 60 seconds my WebSocket connection is automatically closed, but an error isn't thrown. The program just silently stops. However, this similar code in web3.js does throw an error:

const Web3 = require('web3');

let ws = 'ws url';
let web3 = new Web3(new Web3.providers.WebsocketProvider(ws));
let web3Test = async () => { 
  console.log(await web3.eth.getBlockNumber());
  await new Promise(resolve => setTimeout(resolve, 61000));
  try {
    console.log(await web3.eth.getBlockNumber());
  }
  catch (err) {
    // this will show: Error: connection not open on send()
    console.log(err);
  }
}

web3Test();

Is it possible for ethers.js to throw on invalid WebSocket providers or providers where the connection has closed?

[nullvoidobject]

@ricmoo would the best bet be to use a combination of both ethersjs and web3 to catch these errors?

[ricmoo]

I actually haven't used Web3.js in quite a long time. I don't really know how have the two cooperate. Is there a reason to not stick with just one or the other?

You can create a WebSocket manually and pass that in, instead of a passing in a "was://" string, then you can adjust any additional properties on it you want, such as keep-alive.

Keep in mind your service may be what is disconnecting you, in which case that may not matter. If you are running your own instance of Geth, you have more control over its termination of stale sockets. So, it depends on who is hanging up.

[proficy]

Hmm, I'm using the same "wss:// string in both Web3.js and ethers.js. The Geth instance is using Nginx which is set to the default connection timeout of 60 seconds. In Web3.js after 60 seconds, it will throw an error, but in ethers.js it seems to silently fail and doesn't proceed to the next line of execution. I'd prefer to just stick with ethers.js, but I'd like to catch the error and notify my users that the websocket could be down.

The same thing happens if the Geth instance itself is down. ethers.js allows me to create the provider, but the calls don't work and won't throw an error.

[proficy]

@ricmoo to provide a little more context, I have a few Geth instances that my users connect to in a frontend application. If I need to prune an instance, it'll temporarily go down for a few hours. Currently, I use ethers.js exclusively, but it won't throw an error if they connect to the node while pruning. However, if I use Web3.js, I can throw an error and notify them that the node is down and they should use a different one. I'm just looking for a way to achieve this using only ethers

[proficy]

@ricmoo @zemse do you guys know of a workaround for this issue? I'm wondering if combining the web3 library to catch the error is the best way to go for now

[proficy]

@ricmoo @zemse sorry for bugging you, but has an issue been created for this?

[proficy]

@ricmoo @zemse, I just tested on 5.7.1 and this is still an issue

[zemse]

Hey @proficy, sorry about no updates on this. There have been some issues with sockets API on v5 and in ethers v6 it's greatly improved. Unfortunately porting them to v5 may not happen, since the current plan is to only provide security updates to v5.

You can check out the recent eth global keynote for ethers v6 by Richard https://youtu.be/NflOaU6Kgss?t=14266

[proficy]

Hi @zemse and @ricmoo, I just tested the example script I have above in v6 and the issue is still there. Are there any other parameters that need to be passed in to keep the websocket connection alive? The main problem is if I have something like a contract instance connected to a websocket provider, if the websocket is closed the contract will be unuseable because it's now connected to the closed provider. Both the websocket provider and contract need to be reinitialized.