Does the paid tier solve the idle behavior of websocket connections?

It is currently very frustrating to use Infura for listening to events via a WebSocket connection because Infura kicks idle connections out after 10min to an hour. The only work around is to completely restart your script. Does the paid tier have idle disconnections too?

This is a problem in the client implementation (i.e. go-ethereum) of Websockets, we have already released fixes for logs and newhead subscription types and are working on the other subscription types. Can you provide more information about what you’re trying to do over the websocket connection?

I was waiting for replies in the linked thread, where you responded and I provided the use case.

I’m using:

console.log("App Restarted, Current PID: " + process.pid)
setTimeout(function () {
process.on(“exit”, function () {
require(“child_process”).spawn(process.argv.shift(), process.argv, {
cwd: process.cwd(),
detached : true,
stdio: “inherit”
})
})
process.exit()
}, 600000)

To restart things. It’s terrible because it can potentially stall confirmations for end users. I’m listening for approvals in token contracts, and then updating my own contract. The end user is expecting me to update my contract and to provide them a confirmation. This should take less than 45 seconds, and hopefully less than 5 seconds with PoS.

I am keeping track of the last block the contract was updated for queries, so there is the potential for someone to slip between the cracks. If the idle timeouts don’t happen, then I don’t have to restart my script every 6 minutes. The only workaround is two have two different instances overlapping. Then I’m hammering infura even more, and using web 2.0 methods to synchronize. I want the blockchain to be the only database.

What are the specific web3 functions you are using to listen for these token events?

If you are filtering to just your contract, and it’s not getting lots of transactions, then it’s possible no traffic matches your subscription and you your TCP connection is disconnected for being idle. Note that this disconnect happens at the network load balancer level, it’s not something we can control on our side, or we would.

If that’s the case, I would suggest also adding a newHeads subscription which should keep your connection active; you don’t need to process these events, they will just ensure that your connection is receiving traffic and prevent the TCP connection from going stale.

If you are using web3.js, take a look at: https://web3js.readthedocs.io/en/v1.2.0/web3-eth-subscribe.html#subscribe-newblockheaders

I’m using contract.events.method. What happens is that the script appears to function normally, but it’s impossible to reconnect without restarting the script entirely and recovering from there. I have this:

//Infura Websockets connection.
const getProvider = () => {
	console.log('*** getProvider Called ***')
    const provider = new Web3.providers.WebsocketProvider('wss://ropsten.infura.io/ws/API_key')
    provider.on('connect', () => {
    	console.log('*** WebSocket Connected ***')
	})
    provider.on('error', e => {
        console.log('*** WebSocket Error ***')
        getProvider()
    })
    provider.on('end', e => {
        console.log('*** WebSocket Ended ***')
        getProvider()
    })
        provider.on('close', e => {
        console.log('*** WebSocket Closed ***')
        getProvider()
    })
        provider.on('timeout', e => {
        console.log('*** WebSocket Timeout ***')
        getProvider()
    })
        provider.on('ready', e => {
        console.error('*** WebSocket Ready ***')
    })
    return provider

However, none of these ever fire, so they are impossible to use for disconnects.

Note that this disconnect happens at the network load balancer level, it’s not something we can control on our side, or we would.

I don’t quite follow this as it doesn’t compute in my head. :slight_smile: Could you elaborate how this is working at a lower level? I don’t understand how it cannot be possible.

newHeads subscription which should keep your connection active; you don’t need to process these events, they will just ensure that your connection is receiving traffic and prevent the TCP connection from going stale

That’s a good tip. I tried something similar, subscribing to all events of a very active contracts, but I still got idle disconnects quickly. It’s possible that there are other issues at play I haven’t yet figured out. What annoys me most though is I can’t handle the disconnects. There’s no way to tell what is what, and there’s no way to recover besides restarting. I suppose I’m barking up the web3js tree now, but as I ranted to Samuel Furter about cross project communication, there are a lot breaking changes that could be avoided with less insularity. I’m guilty of this myself.

I think most projects will have very thin usage for a while. I don’t expect much traffic, but I’m engineering redundancy to recover from all situations. It’s a major undertaking. I hope to have it figured out by January and PoS. This is when Ethereum booms.