WebsocketProvider disconnect method doesn't close the connection when provider is trying to reconnect

[PierreJeanjacquot]

Description

WebsocketProvider disconnect method doesn't close the connection when provider is trying to reconnect

Expected behavior

Calling provider.disconnect() should always terminate the websocket connection.

Actual behavior

Calling provider.disconnect() doesn't terminate the websocket connection when the provider is trying to reconnect.

Steps to reproduce the behavior

1. run a local node with websocket

2. run the following code with Nodejs

const Web3 = require('web3');
const provider = new Web3.providers.WebsocketProvider('ws://localhost:8546');
provider.on('connect', () => console.log('connect'));
provider.on('error', () => {
  console.log('error');
  provider.disconnect();
});
provider.on('close', () => {
  console.log('close');
});

process logs:

connect

3. Turn off you the local ethereum node
   process logs:

connect
error

the process should log close and exit as provider.disconnect() has been called.

Versions

• web3.js: 1.0.0-beta.55
• nodejs: v12.3.1

Note

Also tested with current code including #2711 correction:

# start nodejs
connect
# shutdown eth node
error
error
...
error
# restart eth node
connect

[nivida]

Thanks for opening this issue! I will test and if required fix it asap.

[7-of-9]

Any update on this? I'm seeing the same behavior (2.0.0-alpha): when trying to attempt to a node without WS interface enabled, auto-reconnect logic kicks in, i.e. attempts reconnect every few seconds.

So far so good, but calling currentProvider.connection.close() or currentProvider.disconnect() does not abort the reconnect logic, and in fact I can't find any way to stop, abort or teardown this web3 instance.

The instance is now a zombie, continually trying to reconnect to a non-existent or non-responsive endpoint, with no way to terminate it. Overwriting the instance with a new one doesn't help; the network monitor shows continuous reconnect attempts.

There really should be a global nuke() method or similar that restores the instance to a pristine state, i.e. deletes all state, subscriptions, connections and reconnection logic, etc.

But more narrowly, calling currentProvider.disconnect() really needs to stop the reconnect logic.

[nivida]

@7-of-9 We are informed about this behaviour but as long as the connected node doesn't close the connection in a clean manner is it impossible for us to handle the manual closing case well.
I'm currently working on the reconnect handling for 1.0 here which will be an improved version of the one we have for 2.0 and I will after forward this fix to 2.0 as well.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment, otherwise this issue will be closed in 7 days

[wbt]

I know it's been a while since the issue was raised; is there any update on its fix?

We are informed about this behaviour but as long as the connected node doesn't close the connection in a clean manner is it impossible for us to handle the manual closing case well.

Even if the connected node doesn't close the connection cleanly, it seems like it should be possible to address this with a boolean variable in the provider object (e.g. 'disconnectCalled') that is default-false and set to true on the first line of the disconnect() handler. Auto-reconnection could check this value before each attempt and if it's true, quit making attempts to reconnect. After successful reconnection, check it again and if true at that point, do the clean disconnection that would've been done if the provider were connected at the time disconnect() was called.