it’s part of the the ‘eth_subscribe’ method. For more info:
https://infura.io/docs/ethereum/wss/eth_subscribe
also:
We realize this is a problem for our users and are in the process of upgrading our subscriptions to be less client dependent.
There’s a massive difference between a frontend client just listening for confirmations and likely having page refreshes, and a backend client managing a contract which will have peaks and lulls depending on the time of day.
Is there an accepted solution for web3? This is game breaking. It is currently too annoying to do with geth. The ridiculous blockchain size and high expense of maintaining this on a remote host discourage most people from even bothering. There’s almost no current Ethereum projects even worth this expense imo.
Edit: newHeads only seems to be for subscriptions, but most people will be using getPastEvents as their subscription method for a backend manager.
Edit 2: After testing, the only way to make a script that listens is to bombard infura with 10,000x the requests as a connection that doesn’t drop would do. Something need to be rethought here. I’m just reconnnecting and rerequesting past events every three seconds instead of just waiting for the events. Sure, I don’t want things to hang so iterating based on a block number getter in the contract, but after it discconects the first time, the only way for things to work is to hammer the node with requests, so better just to do that from the start. I don’t even see the point of a WebSocket connection.
Are you using web3.js to generate your subscription, or a different library?
Web3 1.0 beta 55. All of my tests have been failures. It’s annoying to test because I have to wait about one hour for it to drop each iteration.
Could you explain what data your app is querying? Is it account balances, contract event logs, or just new block information. If I knew a bit more about what youre trying to accomplish I can try to suggest how to optimize.
1 Like
It is listening for approval events (subscriptions) on a token contract and then updating a billing contract based on those events. It has to work all of the time, else people will approve tokens for a subscription, but not get confirmation of billing on the frontend. Missing an event = death.
The list of events can grow very large quickly potentially too, which is a challenge to parse. There’s a lot to engineer redundancy-wise, but getting stuck on the most rudimentary part of it is probably why Ethereum has languished with more bullshit than viable products. :-/
Infura is an invaluable fallback to a local node, which has its own problems with Web3. Hammering every three seconds the same getPastEvents query is not viable.
1 Like
Thanks. That background was helpful. Out of curiosity, would a webhook event delivery be something that would be compatible with your architecture or are you looking for another type of resilient interface for events.
I’m totally agnostic to solutions. I just want something to works, but preferably with an established pattern that I know works. Willing to pay as well for priority.
I think a lot of people are in the same place. Ethereum is pretty much dead in the water until PoS takes hold as well. Ignoring error handling, there’s way too much friction on transactions on the frontend for end users currently from confirmation time and gas price selection. All of these annoyances add up!
Hi guys, I am having the same problem as many in here. I am subscribing to get logs on a couple of contracts and having long-term connection issues. I wrote a simple disconnect/reconnect function to help, but I am still finding it dropping unexpectedly. I see in the FAQ it recommends to ‘ping.’ Has anyone here found a good way to solve this issue?
One additional suggestion from the ping technique is to have a newHeads subscription type in your connection as well. Since the newHeads will come in multiple times per minute your connection will be kept alive via that subscription.
I am wondering the same thing: what is the best way to setup pinging for newBlockHeaders subscriptions?
I saw someone above posted the following code:
this.web3.currentProvider.on('end', () => {
console.log(`websocket session ended. attempting to restart.`);
this.setup();
});
Is there another way?
Can you elaborate on how this would be done?
Most languages have a default ping function for websocket connections. Assume socket is your wss connection, for JS it is socket.send("ping")
Use eventeum and rabbitmq to guarantee delivery of events.
What is the response you are expecting for this method? I am still having issues with Infura dropping wss for just simple operations that aren’t needed all of the time on another project.
connection not open on send()
I am using socket.io to connect to a frontend with the object socket. Not sure how that affects things.
var web3 = new Web3(
new Web3.providers.WebsocketProvider(
"wss://ropsten.infura.io/ws/v3/xxx"
)
)
If I poll with web3.send(“ping”), will that work?
Edit: After some research, Infura breaks things when the connection times out. I need some method to instantiate infura again, because polling and pinging is not going to be a solution. I just need to open a new connection each go, but this time the solution can’t be restarting the script.
It looks like Infura was fixed from last time I tried, however it’s not ideal as there is plenty of lag reconnecting.
20200122T070244.115599: *** WebSocket Ended ***
20200122T070244.784172: *** WebSocket Connected ***
Enough to introduce errors with traffic, but I suppose you wouldn’t be using Infura if this becomes likely. It would be nice to guarantee a connection however. I suppose Web3 is infinitely more likely to throw you a curveball than to get stuck in the gap here, or some other nodejs bug.
Here’s what I did:
const Web3 = require("web3")
//Infura Websockets connection.
var getProvider = () => {
const provider = new Web3.providers.WebsocketProvider(
"wss://ropsten.infura.io/ws/v3/xxx"
)
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("exit", (e) => {
console.log("*** WebSocket Exit ***")
getProvider()
})
provider.on("ready", (e) => {
//console.log('*** WebSocket Ready ***')
})
return provider
}
var web3 = new Web3(getProvider())Hey @Genys , thanks for sharing the code and timestamps. Is that ~0.7 second reconnect time around the mean time? And to clarify based on this thread, are you disconnecting yourself manually and then running getProvider() every 10 seconds? minute? hour?
The 0.7 is about standard, but I’m sure it depends on server location. It’s not a lot, it’s just the idea that I can’t guarantee a websocket request gets processed correctly. It can trigger errors that are so edge that it is easier to ignore them and confuse the user.
Infura just disconnects frequently. Here is from last night:
20200122T074647.415345: *** WebSocket Connected ***
20200122T085327.412680: *** WebSocket Ended ***
20200122T085329.114902: *** WebSocket Connected ***
20200122T100009.116734: *** WebSocket Ended ***
20200122T100009.818641: *** WebSocket Connected ***
20200122T110649.818019: *** WebSocket Ended ***
20200122T110650.448785: *** WebSocket Connected ***
20200122T121330.444977: *** WebSocket Ended ***
20200122T121331.044391: *** WebSocket Connected ***
20200122T132011.043489: *** WebSocket Ended ***
20200122T132016.750672: *** WebSocket Connected ***
20200122T142656.747519: *** WebSocket Ended ***
20200122T142657.435494: *** WebSocket Connected ***
20200122T153337.432157: *** WebSocket Ended ***
20200122T153338.075761: *** WebSocket Connected ***
20200122T154744.064989: Mysql error.
20200122T154744.068026: Success connecting to mysql.
20200122T164018.067290: *** WebSocket Ended ***
20200122T164018.705746: *** WebSocket Connected ***
20200122T174658.700926: *** WebSocket Ended ***
20200122T174659.371240: *** WebSocket Connected ***
20200122T185339.366789: *** WebSocket Ended ***
20200122T185340.036473: *** WebSocket Connected ***
20200122T200020.023967: *** WebSocket Ended ***
20200122T200020.752810: *** WebSocket Connected ***
20200122T210700.602015: *** WebSocket Ended ***
20200122T210701.242267: *** WebSocket Connected ***
Mysql disconnects once per night, but I’m sure when in production this can be solved on a VPS. This is managed hosting.
And to clarify based on this thread, are you disconnecting yourself manually and then running getProvider() every 10 seconds? minute? hour?
I’m not disconnecting, it just goes idle. Before calling Provider() did not work as there was some bug with Infura, now that seems to be rectified. I had to restart the script to reconnect, that was the only workaround previously.
I am not that worried about this disconnect, but it is so ugly that I am spending 95% of my time on just debugging connections related web3, and errors in MetaMask that could be solved easily, but won’t be for months, maybe years.
Ack. Now it goes into and endless loop. No idea how it happened. It just disconnected, and now there is no reconnection. This is aggravating.
20200121T220447.687436: *** WebSocket Error ***
20200121T220447.688115: *** WebSocket Ended ***
20200121T220447.688921: *** WebSocket Error ***
20200121T220447.689543: *** WebSocket Ended ***
20200121T220447.690269: *** WebSocket Error ***
20200121T220447.690709: *** WebSocket Ended ***
20200121T220447.691256: *** WebSocket Error ***
20200121T220447.691684: *** WebSocket Ended ***
20200121T220447.692210: *** WebSocket Error ***
20200121T220447.693076: *** WebSocket Ended ***
20200121T220447.693623: *** WebSocket Error ***
20200121T220447.694063: *** WebSocket Ended ***
20200121T220447.694592: *** WebSocket Error ***
20200121T220447.695020: *** WebSocket Ended ***
20200121T220447.695543: *** WebSocket Error ***
20200121T220447.695957: *** WebSocket Ended ***
20200121T220447.696487: *** WebSocket Error ***
20200121T220447.696937: *** WebSocket Ended ***
20200121T220447.699243: *** WebSocket Error ***
20200121T220447.699701: *** WebSocket Ended ***
20200121T220447.700292: *** WebSocket Error ***
20200121T220447.700717: *** WebSocket Ended ***
20200121T220447.701250: *** WebSocket Error ***
20200121T220447.701666: *** WebSocket Ended ***
20200121T220447.702180: *** WebSocket Error ***
20200121T220447.702607: *** WebSocket Ended ***
20200121T220447.703130: *** WebSocket Error ***