Contract events do not trigger in Status Dapp Browser

[jrainville]

User Story

As a developer, I want to contract events to trigger so that we can have more interactivity in the Dapp.

Description

Type: Bug

Summary: Experienced in the Status Teller Network, web3js contract events never trigger in the Status Dapp browser, but they do work in normal browsers with Metamask (probably because Status doesn't use websocket [WS] to connect to the node)

Expected behavior

Using contract events (https://web3js.readthedocs.io/en/1.0/web3-eth-contract.html#events), should call the callback when the contract interaction happens.

Actual behavior

Nothing happens, the callback is never called.

Reproduction

I created this simple Dapp that has a simple Storage contract: https://jrainville.github.io/events-test/dist/

• Open Status
• Go to Rinkeby (Profile > Advanced > Network)
• Go to Dapp browser
• Go to https://jrainville.github.io/events-test/dist/
• Put a number in the Set field and press "Set"
• Send the transaction
• Wait for "Done" to appear next to the tx hash
  -> There will be no event triggered at the bottom

If you try again in a desktop browser with Metamask (also in Rinkeby), you will see the number you set in the field appear in the Events section

Solution

I'm thinking that Status connects to the blockchain node using RPC only , but RPC doesn't not support events. It should however connect to the node using WS (see Web3js' docs for differences between the providers: https://web3js.readthedocs.io/en/1.0/web3.html#providers)

Additional Information

• Status version: 0.13.0
• Operating System: Android and iOS (also experienced by @iurimatias and @richard-ramos

[jeluard]

@jrainville Could you see anything special in debug logs?
See https://status.im/developer_tools/debug.html

[jeluard]

Also which provider do you use? You should hook with status EIP1102 provider

[jeluard]

Just noticed you shared a URL to test.. looking at it!

[jrainville]

@jeluard I'm setting up my phone to use debug logs, but in the meantime, here's the answer for your question.

which provider do you use? You should hook with status EIP1102 provider

We do use the EIP1102 provider. The Dapp is built using Embark and Embark takes the available provider given by the browser (in this case Status) and calls ethereum.enable on it. We don't decide if we use ws or rpc, we just use what's available.

I'll try to check by logging the provider's details if I can see the url that is used to connect to the node and confirm or not that it uses RPC.

[jrainville]

Just tried debugging and there is sadly nothing in the logs.

[jeluard]

Is the Set action supposed to create a transaction? I can't see a transaction generated in status. I remember @andytudhope had issues with Embark. Maybe he can help?

Status offers a EIP1102 compliant provider following JSON-RPC standard. It is based on a direct protocol, neither HTTP nor WebSocket based. As AFAIK all JSON-RPC methods are supported, all web3.js sugar should work fine. AFAIK we never got any other similar feedback from other apps.

It might be worth checking using something like https://web3js.readthedocs.io/en/1.0/web3-eth-contract.html#getpastevents too?

[andytudhope]

We had weird web3 issues too, but never the contract events not firing. Most issues I ran into had to do with BigNumbers and other such delights. We're definitely still using rpc though...

[jrainville]

Is the Set action supposed to create a transaction?

Oops, just tested again, and while it worked when I tested last time, I might have overwritten the working version. Going to update it right away. Sorry about that.

[jrainville]

Ok, I just "fixed" the Dapp. Basically, the event handler was giving an error in Status that I didn't handle.
The error is:

Error: The current provider doesn't support subscriptions: ReadOnlyProvider
    at Subscription.../../embark/node_modules/web3-core-subscriptions/src/subscription.js.Subscription.subscribe (app.js:formatted:154621)
    at Contract.../../embark/node_modules/web3-eth-contract/src/index.js.Contract._on (app.js:formatted:159943)
    at app.js:formatted:193012
    at app.js:formatted:192051
    at Array.map (<anonymous>)
    at app.js:formatted:192050
    at _callee$ (app.js:formatted:191938)
    at tryCatch (app.js:formatted:138444)
    at Generator.invoke [as _invoke] (app.js:formatted:138669)
    at Generator.prototype.<computed> [as next] (app.js:formatted:138497) null

This error tells me that web3 just doesn't support events with the current provider.

We checked the status-react code and it seems you use your own Provider (https://github.com/status-im/status-react/blob/40aff1da8dc29d961ca806d2b81bcb874f7e4223/resources/js/web3_opt_in.js#L118)

You might need to extend from Web3's WS provider.

[jeluard]

This happens if you call write methods before the successful return and user ack of ethereal.enable()

[jrainville]

Possible. It is not the case in my example though, since, as you can see here https://github.com/jrainville/events-test/blob/master/app/js/index.js#L16, I only call the event registration once EmbarkJS.onReady is done on line 5.

For clarity, EmbarkJS.onReady makes sure to do the connection to the node and do ethereum.enable(). Then it calls back.

[corpetty]

So to be clear, status-react providers are NOT using websockets. In order to fix this, then we need to use them, correct?

[jrainville]

That's my understanding of the problem yes. The Status-React providers are completely custom so they probably need WS support just like Web3js' Websocket provider (https://github.com/ethereum/web3.js/blob/2.x/packages/web3-providers/src/providers/WebsocketProvider.js)

One way to do it would be to find a way to extend the Web3's WS provider like

class ReadOnlyProvider extends WebscoketProvider

Or maybe to make the Status-React use the WS provider and just "override" the send functions, a bit like we do in Embark: https://github.com/embark-framework/embark/blob/master/packages/embark-blockchain-connector/src/provider.js#L134

[corpetty]

this isn't a terribly security sensitive issue. I ask because of V1 audit scope. Events processing in dapps is pretty big though for usability and interactivity within the app.

[churik]

More context in #10809

[cammellos]

Moving to discussion, since this requires probalby a bit more effort