Does Infura support the Web3.js 1.0 API?

[lukehedger]

Using [email protected] I have attempted to deploy a contract to Rinkeby with a single argument:

myContract.deploy({ arguments: [ 123 ] })

The contract deploys OK but when calling a method to return the constructor argument, 0 is returned, which suggests the argument was not processed.

myContract.methods.echo().call({ from: fromAccount })
  .then( res => console.log(res) ) //=> 0

The contract is here for ref:

pragma solidity ^0.4.0;

contract Echo {
  uint value;

  function Echo(uint _value) {
    value = _value;
  }

  function echo() constant returns (uint) {
    return value;
  }
}

[egalano]

Hi @lukehedger we're working on web3.js 1.0 support i.e. scalable websocket support now. It's in early alpha support stage on our side. If you're interested in helping us test it out shoot me your contact info and I'll get you access.

[lukehedger]

Hey @egalano - sounds cool! Would definitely like to help test. Email is: [email protected].

[rhlsthrm]

Hi @egalano, I'd also like to test out the new version. Email is [email protected].

[tensor5]

Hi @egalano, I'd like to try the Web3.js 1.0 support. [email protected]. Thanks

[strelok1]

Would love to get beta access to web3js 1.0 support with web sockets. [email protected]

[rhlsthrm]

Has anyone gotten an email from them regarding this issue? I have not received anything.

[egalano]

Sorry for the delay, I just sent the email with the connection details. Please give it a try and let us know if you encounter any issues.

[strelok1]

Thanks. Got the email. Will report back with any probs. Cheers

[tensor5]

@egalano Thanks!

[DalderupMaurice]

Any estimation when this functionality will be available?
Currently, I have no clue how to watch events whatsoever - while using infura. @egalano
I am also willing to test it :) (Email can be found on my profile)

[miguelmota]

@egalano i'm interested in trying out and testing infura websocket support [email protected]

[ravshanof]

Hi @egalano, happy to test out the alpha version. Email: ravshanoff at protonmail

[christian-valadez]

Hi @egalano , I'd also love to test out the alpha version. Email: [email protected]

[jdkanani]

@egalano Hey I have built infra to listen live events from Ethereum: https://matic.network/dagger
Thought you would find this interesting.

[miguelmota]

Really cool library @jdkanani

[egalano]

Nice @jdkanani . Is that library compatible with any Ethereum node or specifically Geth's pub-sub API.

[jdkanani]

@egalano Unfortunately no.

Problem was that - if you have multiple Geth nodes - you have to deploy filters on every node. Plus, separating filters from Geth will give you more control over filter types. There are some cons too. But overall this will make development very easy for DApps.

[icaroharry]

hey @egalano. I'm trying to listen to an event (with Web3.js) from a contract deployed in Ropsten but I'm getting The current provider doesn't support subscriptions. Is it related to this issue? If so, I'm interested in testing the websocket support. Email: [email protected]

Thanks in advance!

[egalano]

Hi @icaroharry yes our API does not allow stateful requests at the moment. Our JSONRPC API endpoint currently load balances requests between many backend Ethereum nodes to be able to handle our large request volume. This is why we don't allow event subscriptions which use eth_newFilter and eth_getFilterLogs. Typically people are using eth_getLogs method and polling to be able to simulate the behavior of an event subscription. Or you can try out our websocket endpoint which we have been working on which should finally deliver this desired feature to users.

[jdkanani]

@icaroharry How did you solve this problem then? Just curious.

[carlolm]

@egalano hi can I try out websocket beta also? I am working on a DApp requiring real time event updates. Thanks! [email protected]

[icaroharry]

@jdkanani I'm working on an alpha version of a DApp, so temporarily I implemented a good old "refresh button" that calls web3.contract.getPastEvents 😄

Now I'm going to test the websocket. Kudos to @egalano

[jdkanani]

@icaroharry Great. And, @egalano what did you change at Infura to solve problem of "installing same filters on all nodes"?

[MisterDr]

Hi @egalano, could you please add me to WS beta at: [email protected]. Thank you :)

[LefterisJP]

Hey @egalano could I get beta acces to websocket support? [email protected]

[afiorenza]

Hi @egalano do you have an ETA for this? Thank you.

[ghost]

Hey @egalano .. Please send me details also i would love to be alpha tester for this. Thanks. [email protected]

[maxsupera]

i would also love to get some of that sweet websocket access. please add meeee!!!! :D [email protected]

Thanks!

[jamboj]

@egalano,
Hi, thank you for posting the above code snippet - it does indeed work for me and runs without issues for hours.

However, when subscribing for events, I get Connection dropped by remote peer. disconnects every few minutes.

My question is:

1. Is this normal/expected?
2. If not, do you immediately see anything wrong with my code or could it be node issue?
3. If yes, how can I handle this/resubscribe properly?

Many thanks in advance.
Here is my code:

const Web3 = require('web3');
const web3 = new Web3(new Web3.providers.WebsocketProvider('wss://mainnet.infura.io/ws'));
var ckAddress = '0x06012c8cf97BEaD5deAe237070F9587f8E7A266d';
var ckABI = [{"constant":true,"inputs":<...>]
var ckContract = new web3.eth.Contract(ckABI, ckAddress);

var birthEvent = ckContract.events.Birth(eventHandler);

function eventHandler(error, result) {
        if(!error) { console.log("*** Kitty born:", result); }
        else { console.log("*** Birth event handler error", error); }
};

And the console output:

MacBook-Air:testdir testuser$ node testck.js 
*** Kitty born: { address: '0x06012c8cf97BEaD5deAe237070F9587f8E7A266d',
  blockNumber: 5084578,
<...>
     topics: 
      [ '0x0a5311bd2a6608f08a180df2ee7c5946819a649b204b554bb8e39825b2c50ad5' ] } }

etc, then the disconnect:

connection not open on send()
*** Birth event handler error _Event {
  type: 'close',
  isTrusted: false,
  _yaeti: true,
  code: 1006,
  reason: 'Connection dropped by remote peer.',
  wasClean: false,
  target: 
   W3CWebSocket {
     _listeners: {},
     addEventListener: [Function: _addEventListener],
     removeEventListener: [Function: _removeEventListener],
     dispatchEvent: [Function: _dispatchEvent],
     _url: 'wss://mainnet.infura.io/ws',
     _readyState: 3,
     _protocol: undefined,
     _extensions: [],
     _bufferedAmount: 0,
     _binaryType: 'arraybuffer',
     _connection: 
      WebSocketConnection {
        _debug: [Object],
        domain: null,
        _events: {},
        _eventsCount: 0,
        _maxListeners: undefined,
        _pingListenerCount: 0,
        config: [Object],
        socket: [Object],
        protocol: undefined,
        extensions: [],
        remoteAddress: '34.200.180.219',
        closeReasonCode: 1006,
        closeDescription: 'Connection dropped by remote peer.',
        closeEventEmitted: true,
        maskOutgoingPackets: true,
        maskBytes: <Buffer a0 78 ef 90>,
        frameHeader: <Buffer 81 7e 03 47 00 00 00 00 00 00>,
        bufferList: [Object],
        currentFrame: [Object],
        fragmentationSize: 0,
        frameQueue: [],
        connected: false,
        state: 'closed',
        waitingForCloseResponse: false,
        receivedEnd: true,
        closeTimeout: 5000,
        assembleFragments: true,
        maxReceivedMessageSize: 8388608,
        outputBufferFull: false,
        inputPaused: false,
        receivedDataHandler: [Function: bound ],
        _closeTimerHandler: [Function: bound ],
        webSocketVersion: 13,
        socketHadError: false },
     _client: 
      WebSocketClient {
        domain: null,
        _events: {},
        _eventsCount: 0,
        _maxListeners: undefined,
        config: [Object],
        _req: null,
        protocols: [],
        origin: undefined,
        url: [Object],
        secure: true,
        base64nonce: 'KmbbgDWMKyHgvjWfYhzvTA==',
        socket: [Object],
        response: [Object],
        firstDataChunk: null },
     onerror: [Function],
     onclose: [Function],
     onmessage: [Function] },
  cancelable: true,
  stopImmediatePropagation: [Function] }
MacBook-Air:testdir testuser$ 

[jamboj]

debugging a bit more it seems the disconnect happens after exactly 5 mins of inactivity. I.e. no events for 5 mins -> Connection dropped by remote peer

so what's the best way to deal with this when watching a not very active contract?

[StarNeit]

@ncocchiaro , Thank you.

I solved problem by using getTransactionReceipt. 👍 👍 👍

[StarNeit]

Hi, @jamboj
You're right. Connection dropped every 5 minutes by remote peer.
It was working correctly, but now it is being dropped frequently.

Error is:
Error: connection not open

Did you find solution already, @jamboj ? Thanks.

[jamboj]

Hi @StarNeit,

My solution (although incomplete) is to subscribe to blocks like in @egalano's example above: this keeps communication with the peer up, however it is not bulletproof (i.e. if there's no blocks for 5+ mins, it will still disconnect) and also doesn't address a more general question of handling any disconnects/resubscribing.

Hope this helps, let me know if you have any follow up questions/need more detail

[egalano]

Hi guys now that our websocket support is live I’m going to close this ticket so it doesn’t become a monolithic bug tracker for subscriptions. Please keep filing issues if you encounter them and we’ll take care of deduplicating tasks for our devs. Let’s start with creating a separate ticket for the issue where people are encountering websocket timeouts as that requires implementation of ping and pong messages in the websocket client and server per the Websocket RFC. https://tools.ietf.org/html/rfc6455

[ericxtang]

Question - should we add our own tokens to the URL? I know it doesn't work right now, but what can we expect about that?

[ryanschneider]

We will eventually provide a separate method for authenticating your account with web sockets, but haven't fully decided on the implementation yet, in the mean time no, you do not need to include your token on the URL.

[jchittoda]

We are building an app @ ETHLend.io that would require Log Event listening. I saw that people have submitted their email ids to test WebSocket beta. Here is my email [email protected] if some info you think I should know. I see most of the information is already shared here. If something is not shared, please do shoot me email.
I am planning to use Web3j Java library as I am writing Java application. I need to see how this will be integrated with Web3j library.

[noprom]

Hi, do you all solve your problems?
I also encountered this problem:

Error: CONNECTION ERROR: Couldn't connect to node on IPC.
    at Object.InvalidConnection (webpack-internal:///845:35:16)
    at WebsocketProvider._timeout (webpack-internal:///865:192:48)
    at WebSocket.connection.onclose (webpack-internal:///865:96:15)
From previous event:
    at PromiEvent (webpack-internal:///343:35:24)
    at send (webpack-internal:///52:446:21)
    at Object._executeMethod (webpack-internal:///860:819:24)
    at Object.method (webpack-internal:///87:44:66)
    at eval (webpack-internal:///87:487:22)
    at new Promise (<anonymous>)
    at new F (webpack-internal:///41:35:28)
    at Xflip.accessContractWithWeb3 (webpack-internal:///87:480:14)
    at eval (webpack-internal:///87:41:15)
    at new Promise (<anonymous>)
    at new F (webpack-internal:///41:35:28)
    at Xflip.getContractData (webpack-internal:///87:40:14)
    at Vue$3.initXflip (webpack-internal:///237:105:84)
    at Vue$3.boundFn [as initXflip] (webpack-internal:///7:192:12)
    at eval (webpack-internal:///237:82:13)

It works fine for wss://ropsten.infura.io/ws but wss://mainnet.infura.io/ws will throw this error.

[Plinpod]

I'm having the exact same issue as @jamboj does anyone have a solution here?

[ericxtang]

@Plinpod @jamboj we had that problem too. We ended up adding retry logic in our software - here the PR https://github.com/livepeer/go-livepeer/pull/320/files

[habdelra]

@noprom @Plinpod have you tried using the _ws endpoint? like wss://mainnet.infura.io/_ws?

[Plinpod]

@habdelra I did switch to the _ws endpoint and it seems more stable for me, however I do still get the same issues after it runs for awhile.

@ericxtang So with web3, I would basically just re-initialize the events everytime they error out?

[ericxtang]

@Plinpod haven't tried in web3, but that seems reasonable (if initializing the event actually establishes a new connection).

@habdelra What's the difference between /_ws and /ws?

[ryanschneider]

/_ws is our older endpoint that forwards straight to geth. It's only suggested if you requiring batch support, and only then until we get batch support implemented in our proxy at /ws. It will be deprecated at some point once our proxy supports all required features, and may be rate-limited if we see it being abused in any way.

In general, you should code your websocket connection with the expectation that you will lose connectivity at some point and need to re-establish your subscriptions. Whether using our shared endpoint or your own node, there will be times when maintenance or network connectivity issues occur and the connection needs to be terminated, so your code needs to handle re-connecting when that happens, and should re-subscribe to events it cares about.

I don't believe Geth's rpc/client module does not do this for you, so you need to add your own logic to resubscribe on top of it.

[guix77]

Looking forward for progress on this

[ryan-rowland]

I'm working on a WebSocket provider for MetaMask's Web3 1.0 provider (MetaMask/web3-provider-engine#227)

Running against wss://ropsten.infura.io/ws, wss://rinkeby.infura.io/ws and wss://mainnet.infura.io/_ws I'm getting normal behavior, a dropped connection every few minutes or so which is manageable.

However, on wss://mainnet.infura.io/ws I'm getting disconnected with 1006s every few seconds. It's so frequent that I can't reliably get a response for my queries most of the time.

It was recommended that we point to /ws but the current behavior I'm observing isn't viable. Is there some specific reason I might be hitting such terrible connectivity here? Some thing I can change / accommodate for in my own code?

[ryanschneider]

@ryan-rowland Can you open a separate issue instead of commenting on this closed one? Please include some logs of RPC traffic that show the issue, specifically any traffic sent before the disconnects and the full JSONRPC payload for the 1006 error you are seeing. Thanks!

[egalano]

Hi folks, as mentioned above, we now support Web3js-1.0 subscriptions via websockets. If you are having any issues with our websocket feature please file a separate issue so we can better track and get it resolved. Locking this thread to keep things organized. Thanks!