Its not idle connections per se, more really a connection that is subscribing to all events on a smart contract. Thats it really. As for the ‘newHeads’ subscription, how is this activated/used? Sorry, never came across this before.
it’s part of the the ‘eth_subscribe’ method. For more info:
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.
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.
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!