CONNECTION ERROR: Provider started to reconnect before the response got received!

[snitovets]

I looking for workaround how to handle this error within my app. It was a surprise why websocket not store pending request to resolve after reconnection.

/app/node_modules/web3-core-helpers/lib/errors.js:63
return new Error('CONNECTION ERROR: Provider started to reconnect before the response got received!');
Error: CONNECTION ERROR: Provider started to reconnect before the response got received!
at Object.PendingRequestsOnReconnectingError (/app/node_modules/web3-core-helpers/lib/errors.js:63:16)
at /app/node_modules/web3-providers-ws/lib/index.js:332:37
at Map.forEach ()
at WebsocketProvider.reconnect (/app/node_modules/web3-providers-ws/lib/index.js:331:28)
at WebsocketProvider._onClose (/app/node_modules/web3-providers-ws/lib/index.js:149:14)
at W3CWebSocket._dispatchEvent [as dispatchEvent] (/app/node_modules/yaeti/lib/EventTarget.js:115:12)
at W3CWebSocket.onClose (/app/node_modules/websocket/lib/W3CWebSocket.js:228:10)
at WebSocketConnection. (/app/node_modules/websocket/lib/W3CWebSocket.js:201:17)
at WebSocketConnection.emit (node:events:379:20)
at WebSocketConnection.EventEmitter.emit (node:domain:470:12)
at WebSocketConnection.handleSocketClose (/app/node_modules/websocket/lib/WebSocketConnection.js:389:14)
at TLSSocket.emit (node:events:391:22)
at TLSSocket.EventEmitter.emit (node:domain:470:12)
at node:net:667:12
at TCP.done (node:_tls_wrap:573:7)

Originally posted by @snitovets in #1354 (comment)

[GregTheGreek]

From my understanding, you're hoping that web3js acts stateful and maintains a cache of the web socket events?

[snitovets]

Yes. I hoped ws natively caching pending requests. Should I have to manually store pending requests while provider reconnects? And how to handle this error? provider.on('close', ...) ?

[GregTheGreek]

Typically speaking, we try to be as stateless as possible (there's a few areas where we obviously cannot be). What i would do is perhaps keep track of the last seen block by your application and on a failure case restart using fromBlock

[spacesailor24]

Hey there, just wanted to check if Greg's recommendation satisfies your request?

[snitovets]

Not really, I can't imagine how to apply such idea to my needs. This error happens if transaction sent and reconnection happens while i'm waiting for transactionReceipt event.

[joeytwiddle]

@snitovets In case it helps you: In our organisation, we don't rely on waiting for the receipt. There are multiple reasons why we cannot rely on it:

1. A network error such as the one you are experiencing
2. Perhaps our API server or our geth node is restarted, while waiting for the transaction to be mined. In that case no receipt is received.
3. If there is high congestion, we might get a timeout while waiting for the transactionReceipt. But if the gasPrice is sufficient, that transaction will usually get mined later. But by then it's too late, we won't see the receipt from it. (At the time we wrote the system, web3 would not let us configure that timeout to be longer.)
4. Perhaps most importantly: the transaction is mined with 2 blocks confirmation, but that block is later discarded (becomes an uncle block), so this receipt is not really valid anyway!

In light of this, we don't really pay much attention to the returned receipts.

What do we do instead?

1. We get the transaction hash from the request, before we send it:

      const transactionHash = '0x' + signedTransaction.hash().toString('hex').toLowerCase();
      // not sure if toLowerCase() is really needed or desirable

2. We store that somewhere stateful, e.g. the DB (in case our API server crashes or is restarted).
3. We have a loop running (even after API restart) that looks up that transactionHash on the blockchain, and waits until it is seen 20 blocks behind the head. Only then we can be confident that the transaction was mined and confirmed. Then we can get the transaction receipt object from the blockchain.

That's obviously more steps, but hopefully a bit more robust.

I would also appreciate if anyone has any criticism of our process!

[joeytwiddle]

By the way, did you ever find out why this error was occurring? I would like to compile a list of reasons and solutions in #4016.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions. If you believe this was a mistake, please comment.

[srpatel19590]

I'm facing the same issue.

Error: PollingBlockTracker - encountered an error while attempting to update latest block:
Error: CONNECTION ERROR: Provider started to reconnect before the response got received!

@snitovets Did you manage to fix this?

[zOthix]

Having the same error did any one manage to fix it?

[SalmaanChicmic]

Same error! Any Updates?

[srpatel19590]

Public and shared RPC instances are restarting WebSocket connections sometimes. Hence we get this error. Using the dedicated RPC instance solved this problem for me

[joeytwiddle]

Yes, we also had to give up on ws:// so now we only use http:// to communicate with the geth node.

[rj03hou]

Same error! Any Updates?
close by timeout 😓