Are WebSockets production ready?

[ghost]

In the past day or so, I've been testing out Infura websocket endpoints at

wss://mainnet.infura.io

for Web3 1.0 compatibility. It seems that it's randomly disconnecting, does not support long running subscriptions (like for example subscribing to events generated by a contract), and some methods like getBlock() are not working.

Can we get some clarity on the state of Infura WS?

FWIW, the wss://mainnet.infura.io/_ws endpoint seems to be working more reliably than wss://mainnet.infura.io/ws.

Infura with HTTP is awesome. We rely on it every day. Thank you for your incredible work!

[igi888]

I am having the same problem.

But for me, even the wss://mainnet.infura.io/_ws endpoint stopped working. I am using it for subscribing to events in order to show the UI realtime. It was reliable for at least a month for me, until a few days ago when it stopped working totally.

I am also grateful for the great work the Infura team does!

[flute]

same to me
I tried use wss://mainnet.infura.io/ws and wss://mainnet.infura.io/_ws both. I am using it for subscribing latest transaction. It just works well at first minutes, then lose connect Error: CONNECTION ERROR: Couldn't connect to node on WS.

[Plinpod]

Same issue here. Losing connection randomly

[kennethsoftware]

Having similar issues here, randomly dropping connection on wss://rinkeby.infura.io/_ws, especially if an increased amount of events start to come through. Can't even use the wss://rinkeby.infura.io/ws endpoint to see if that's any better (anyone able to confirm?) but I that's a web3 issue to be fair.

[MeoMix]

Infura's websockets aren't quite production ready yet, but they will be soon.

http://status.infura.io/ will have websocket providers added to it when they are production ready. For now, assume that the endpoints will go up/down as they work on the architecture.

MetaMask's InPageProvider provides a polyfill for subscription support. This is probably your best bet if you're trying to go to production now.

[porteron]

I can't wait until they get the wss stable. Such a useful service for the future development of dapps.

[elie222]

Agreed. Can't wait for this to be production ready. Constantly getting:
CONNECTION ERROR: Couldn't connect to node on WS.

[lakamsani]

Hi, for those using Infura websocket provider do you have to supply your API key in the url like we do with the http provider i.e.https://rinkeby.infura.io/api-key? If so what is the format? Or is the WS provider only for reading/listening to events so there is no need for an API key?

[MeoMix]

@lakamsani The latter. There's no need to specify an API key.

[elie222]

Any idea when this will be production ready?

[downitch]

Any updates on this topic? @MeoMix as far as I see, you have some info about it :)

[sjalq]

Any updates on this yet?

[uneeb123]

+1 on this.

[ryanschneider]

If you have specific issues with websockets please open a new ticket with a reproducible test case.

[yarrumretep]

+1 on this - I've been working with wss://kovan.infura.io/ws for a while now - and mostly it works well. However, sporadically I see:

index.js:33 WebSocket connection to 'wss://kovan.infura.io/ws' failed: Received a broken close frame containing a reserved status code.

followed by several:

index.js:2178 connection not open on send()

At this moment (10:39AM US Eastern, Oct 12, 2018), I've been unable to connect for > 10 minutes.

Does infura recommend that users implement gracefully degrade to http with polling for filters?

[ryanschneider]

@yarrumretep I see no indications of any issues on our end, if it happens again can get a wireshark/tcpdump of an attempted connection?

While you may occasionally be disconnected during maintenance or due to network timeouts, you should be able to immediately reconnect (any maintenance we do is via rolling deploys, but we didn't do any maintenance today and everything in the logs and monitoring looks normal).

[yarrumretep]

@ryanschneider - here's a wireshark from today. Still seeing this sporadically. Also seeing some 404 errors occasionally during WS connecting.

Seems like the problem was with 54.174.165.50 - this occured around 15:14 US Eastern time on October 18.

capture - 201810181514.pcapng.zip

[kingflurkel]

We're having similar results, more and more we see this err.
(https://test.swarm.city)

[ryanschneider]

I think we've found the issue, it looks to be a bug in our infrastructure layer which is adding the wrong instances to the load balancer (a couple unrelated servers that unfortunately pass the same health check). Investigating now.

[xardass]

We're having similar results, more and more we see this err.
(https://test.swarm.city)

stack: "Error: connection not open↵    at WebsocketProvider.send (/root/node_modules/web3-providers-ws/src/index.js:266:18)↵    at RequestManager.send (/root/node_modules/web3-core-requestmanager/src/index.js:132:66)↵    at sendRequest (/root/node_modules/web3-core-method/src/index.js:563:42)↵    at Eth.send [as getBlockNumber] (/root/node_modules/web3-core-method/src/index.js:584:13)↵    at Object.func (/root/src/subscriptions/subscriptionTxHistory.js:214:43)↵    at <anonymous>"

[ryanschneider]

Ok, the issue is resolved and we're working on determining a) how it happened and b) mitigations to make sure it doesn't happen again.

For those curious, this AWS bug seems to be the root cause, or at least related:

https://github.com/aws/amazon-ecs-agent/issues/1417

[xardass]

Our problem persists (see my comment above for console output). We are using Kovan.

[ryanschneider]

@xardass that appears to be a separate issue, can you open a separate GitHub issue, ideally with details on the exact eth RPC you are trying to send and any additional logs?

[xardass]

Thank you, but we narrowed our problem down to a parity update, unrelated to web3.

[yarrumretep]

@ryanschneider - I'm still seeing this with wss://kovan.infura.io/ws

WebSocket connection to 'wss://kovan.infura.io/ws' failed: Received a broken close frame containing a reserved status code.

capture - 201810190941.pcapng.zip

[ryanschneider]

@yarrumretep can you provide more details on what state your client connection was in at the time? Since everything is in TLS I can't see the actual payloads, but it seems like the issue happened a couple seconds after the session was negotiated so if you could log on your end what you were sending to the server that would help debug.

Also, if you wanted to see the payloads yourself and are generating the traffic from a browser, you can use this method:

https://jimshaver.net/2015/02/11/decrypting-tls-browser-traffic-with-wireshark-the-easy-way/

However if you do so please don't post the sslkeylog file, since it appears that it would contain session keys for all of your recent TLS sessions, so could be used by an eavesdropper to decrypt your other TLS traffic.

[hadarbmdev]

WebSocket connection to 'wss://kovan.infura.io/ws' failed: Received a broken close frame containing a reserved status code.

Issue also happens here.

[rmujica]

I am having the same issues while connecting to wss://kovan.infura.io/ws using the latest web3-1.0 release

[neocybereth]

I'm having the same issue on mainnet with an infura node

[mindfulme]

same, nothing helps 👎

[ianaz]

Same issue here, all good on ropsten but on mainnet I get disconnected

[neocybereth]

any updates on this? I'm still getting:

MacBook:seemagin35307$ (node:37749) UnhandledPromiseRejectionWarning: Error: Connection error: Connection is not open on send()

[ianaz]

In our case the issue was that we were loading too much data through eth_filterLogs. In Ropsten there was much less data, therefore the websocket connection wasnt closing. Hope helps someone

[neocybereth]

@ianaz how do you manage how much data you load through eth_fitlerLogs?

[ianaz]

@Sm00g15 by loading the data in smaller batches with fromBlock and toBlock. Before we're loading like 100k blocks at a time, now we reduced to 3000 and looks good

[miguelmota]

Started experiencing the issue as @hadarbmdev:

[CQBinh]

Base on docs, let use v3 scheme:
wss://mainnet.infura.io/ws/v3/YOUR-PROJECT-ID