Web3.js: websocket issues: connection not open on send()

[saitam1]

I am running [email protected] on Kovan + Infura.
The mention issue happens only sometimes and my feeling tells me it happens more often if you didn't run the application for a longer time and then start everything.

[nodemon] 1.18.3
[nodemon] to restart at any time, enter `rs`
[nodemon] watching: *.*
[nodemon] starting `node API.js`
Listening on port 4000...
connection not open on send()
connection not open on send()
connection not open on send()
connection not open on send()

Here is my nodejs code:

const contractFunction = myContract.methods.updateLevel(Number(_myVal));
const functionBytes = contractFunction.encodeABI();

//construct the Tx data
const rawTx = {
    chainId: 42,
    gasLimit: web3.utils.toHex(5000000),
    to: contractAddress,
    from: addressFrom,
    data: functionBytes
    };

//sign & send Tx
web3.eth.accounts.signTransaction(rawTx, privateKey)
    .then(RLPencodedTx => {

    let executed = false;    //to avoid double callback
    myContractWebSocket.once('Events1',
        function(error, event) {
            if (!executed) {
                executed = true;
                if (!error) callback(event, null); 
                else callback(null, error);
            }
        }
    );

    myContractWebSocket.once('Event2',
        function(error, event) {
            if (!executed) {
                executed = true;
                if (error) callback(null, error);
                //If no error wait 1 sec in case Events1 is available, so it can go first
                else setTimeout(function() {callback(event, null);}, 1000);
            }
        }
    );

    //sending signed Tx
    web3.eth.sendSignedTransaction(RLPencodedTx['rawTransaction'])
    .on('error', error => { callback(null, error); });      
})
.catch('error', error => callback(null, error));

[schmidsi]

We had a similar issue and it had to do with the Ethereum Node that we were running and not with web3.js. Troubleshooting revealed that we had malconfigured our nodes.

Are you running a local node or connecting to infura? Are you running a parity node or geth? Are you sure that you enabled websockets properly?

[saitam1]

I ran Infura when this happened. The websocket configuration was as follows:

const web3wss = new Web3('wss://kovan.infura.io/ws');
var myContractwss = new web3wss.eth.Contract(ABI, contractAddress);

[schmidsi]

Then it is probably an issue with Infura. See: https://github.com/INFURA/infura/issues/97#issuecomment-429349516

Try to run your own node and connect to this (this is recommended anyways).

[Truthsayer1]

Just a general observation is this has been happening for a very long time now so I think it's some deliberate policy with the websockets. I'm no expert but the wss://mainnet.infura.io/_ws is better usually than wss://mainnet.infura.io/ws and is a lot faster too it seems. Is there any other one we could be using instead?

One thing nobody mentioned is that if the IP address is changed (via VPN extension in chrome browser, for example) then it starts working again straight away which is why it must be some IP blocking system when too much is requested from one IP.

[lamartire]

Reproduces every time at firefox on our node, but at safari and chrome it works stable.
I think this issue can not be fully relate to infura for these reasons.

[nivida]

This should be fixed with the new WebsocketProvider I've implemented in #2000. I will release it with the version beta.38.

[CQBinh]

@nivida Still, experience this error on beta.54

[dwalintukan]

In regards to this issue still persisting on 1.0.0-beta.54, why is there no open issues about this?

I am having to restart my server almost daily as it seems to get overloaded and repeatedly get the error Connection error: Connection is not open on send().

My server constantly calls getPastEvents as our dapp requires constant and updated information. Previously when I was using HttpProvider for these calls, it would eventually get overloaded and stop which I am guessing is from too many connections opens.

I just changed it to WebsocketProvider and works great for a while (about a day), but then seems to stop being able to call a contract after this period of time. Then any call with the same Web3 instance doesn't go through and my server stops "syncing".

I figure I will just go back to using HttpProvider and reduce the number of parallel calls at a time, but hoping this gets addressed soon. Thanks!

[dwalintukan]

Is this going to be addressed?

[lucashenning]

This is still an issue in v1.2.1 - Error: connection not open on send()
We're using the latest infura api wss://ropsten.infura.io/ws/v3/

[conscott]

Also seeing this on v1.2.1

[deacix]

Also seeing this on v1.2.1

Please open this issue! The problem is still existing! We have on https://1inch.exchange the same problem!
How can i react if this error is throwing?

[jack0son]

Also seeing this on v1.2.1 with wss://ropsten.infura.io/ws/v3/

[conscott]

@jgitgud I had to upgrade to 2.0.0-alpha1 as a workaround until this is fixed

[jack0son]

@jgitgud I had to upgrade to 2.0.0-alpha1 as a workaround until this is fixed

Thanks @conscott. I've managed to get around this issue by re-instantiating web3 on failed sends and pinging the connection with web3.eth.net.getId() - hacky solution, but necessary to avoid attempting a change to the web3 version.

[caa1982]

same issue on v1.2.2 "wss://mainnet.infura.io/v3/"

[caa1982]

any luck on this?

[jack75015]

Let's go fix it plz :) :)

[nivida]

@jack75015 @caa1982 the PR is on the way for 1.x: #3190

[Kondax]

This is still an issue, even with #3190. I am currently on 1.2.7-rc.0 and still receiving this same issue with Infura ropsten websocket.

[cgewecke]

@kondax Could you share your provider configuration? Have you enabled auto-reconnect?

The relevant section in the 1.2.7-rc.0 docs is here

[Kondax]

@Kondax Could you share your provider configuration? Have you enabled auto-reconnect?

The relevant section in the 1.2.7-rc.0 docs is here

I haven't configured the provider apart from supplying a connection URL. Apologies, I wasn't aware of the reconnect option in 1.2.7-rc.0. I will try that now and update you if I see the error occur again.

[cgewecke]

@Kondax Awesome, thank you. This feature is a little tricky to test here since it's network contingent.

Would welcome any feedback about how it performs in the real world 🙂

Please feel free to open a new issue if you're still seeing drops.