Not getting success callback/ receipt with walletconnect with web3.js 1.3.3

[imaksp]

Expected behavior

• It should give success callback & receipt if used with WalletConnect

Actual behavior

• After 1.3.x update (tried with 1.3.3 & 1.3.4 rc.1), it is working upto below callback

.on('transactionHash', function(hash){
    ...
}) 

on 'receipt' OR below one

.then(function(receipt){
    // receipt can also be a new contract instance, when coming from a "contract.deploy({...}).send()"
});

Never gets called but it is working fine with web3.js 1.2.11.

Steps to reproduce the behavior

1. Connect wallet by scanning QR code with Metamask mobile or WalletConnect supported wallet app
2. Do any contract interaction Txn (using myMethod(123).send)
3. See if its calling final success callback with receipt

Logs

Environment

WalletConnect web3 provider: tried 1.3.1 & current latest 1.3.4
Node: 14.15.x
web3.js: 1.3.3 & 1.3.4.rc1
OS: Mac OS 11.1

If possible please release new 1.2.x version with Metamask hotfix, if it can't be fixed quickly with 1.3.x

[GregTheGreek]

By chance do you have a demo app?

[imaksp]

No I don't have demo app, let me know if it is required, will make it tomorrow.

[spacesailor24]

For a sanity check, I tested this locally using ganache-cli by deploying the SimpleStorage.sol contract and submitted a set transaction - I received the transactionHash, the receipt, and the confirmation events

[spacesailor24]

No I don't have demo app, let me know if it is required, will make it tomorrow.

If you could provide a demo app, it would help debugging tremendously

[imaksp]

@spacesailor24 Ok will try to make demo, btw I tried approve method of ERC20 contract & wallet was connected using metamask mobile app on Android using Walletconnect QR code, on rinkeby test network.

Btw it is working as expected with metamask browser extension but not with Walletconnect so we downgraded app to 1.2.11.

[ujal]

I am having the same issue with ganache-cli. The contract deploys but the transactionHash is always undefined. The then callback is never called too. The issue is happening on web3-eth-contract@1.3.4.

[imaksp]

@spacesailor24 Hi, here is the demo app for the issue, please see README for steps, don't forget to set 'REACT_APP_INFURA_ID' in '.env' before connecting.
Demo link: https://github.com/aksdevac/wc-web3-demo

[spacesailor24]

I am having the same issue with ganache-cli. The contract deploys but the transactionHash is always undefined. The then callback is never called too. The issue is happening on web3-eth-contract@1.3.4.

Could you provide a code snippet of what's not working? I can do the same for code that was working using ganache-cli

[spacesailor24]

Forgot to @ujal ^

[spacesailor24]

@spacesailor24 Hi, here is the demo app for the issue, please see README for steps, don't forget to set 'REACT_APP_INFURA_ID' in '.env' before connecting.

Demo link: https://github.com/aksdevac/wc-web3-demo

Awesome, thank you! I'll be taking a look at this shortly

[ujal]

@spacesailor24

contract.deploy({ data: bytecode }).send({ from: account }, function(err, transactionHash) {
  console.log(transactionHash)
}).then(function(newContract) {
  console.log(newContract.options.address)
});

[spacesailor24]

@ujal Here is a working example

[spacesailor24]

Thank you for providing the test repo ❤️

It looks like I received the tx hash using web3@1.3.4

[imaksp]

Thank you for providing the test repo ❤️

It looks like I received the tx hash using web3@1.3.4

Yes txHash is received but receipt is never received with 1.3.4 so loading never stops.

[spacesailor24]

Oops I misread! @ujal said the tx hash was never received

I'll have to take a look at it further tomorrow morning, sorry for the inconvenience!

[imaksp]

Ok @ujal issue might be different but if you check code he posted, he is not listening for transactionHash event, so may be he didn't checked for it. I was also not listening for transactionHash event before as I can show success only after receipt is received & Receipt also has txHash, txHash event is added just for debugging purpose. Goal is to receive the receipt after transaction is confirmed on blockchain.

[spacesailor24]

I updated my example repo above to include the receipt listeners here
Both .on('receipt', receipt => {...}) and .then(receipt => {...}) work, so my suspicion is a miscommunication between WalletConnect and Web3.js

[GregTheGreek]

@pedrouid can you see if @walletconnect/web3-provider is causing this issue?

[imaksp]

@spacesailor24 yes there must be some miscommunication but as it was working with web3 1.2.11, I have created an issue here.

[avinashbuddana]

it is perfectly working on version 1.2.11 .1.3 version has some issues in getting the receipt hook

[imaksp]

@spacesailor24 Hi, any update on this, are you sure its not a web3.js issue? if yes then why its working correctly with 1.2.11 ?

[StillFantastic]

My dapp also not getting a callback when connecting through WalletConnect, the web3 version we are using is 1.3.0

[clexmond]

I'm having the same issue (web3 1.3.4) while connecting with mobile MetaMask via WalletConnect and listening for events with https://web3js.readthedocs.io/en/v1.3.4/web3-eth-contract.html#contract-events. Works just fine with MetaMask extension in browser. I've confirmed Infura is setup correctly in the WalletConnect provider.

[clexmond]

I'm having the same issue (web3 1.3.4) while connecting with mobile MetaMask via WalletConnect and listening for events with https://web3js.readthedocs.io/en/v1.3.4/web3-eth-contract.html#contract-events. Works just fine with MetaMask extension in browser. I've confirmed Infura is setup correctly in the WalletConnect provider.

I have since removed subscriptions as it seems they're not supported with WalletConnect's provider, but the issue remains.

[jeromevvb]

Same issue, using web3 1.3.4 cannot get callback.
i tried all of the callback methods documented here: https://web3js.readthedocs.io/en/v1.2.11/web3-eth-contract.html#methods-mymethod-send but any of them works.

[jeromevvb]

just installed web 1.3.5 and its working now.

this is my code by the way

contract.methods
      .buy()
      .send({ from: wallet.address, value: ether })
      .on("transactionHash", (hash) => {
  

      })
      .catch(() => {
      
      });`

[imaksp]

@jeromevvb your code will work, transactionHash is being received in 1.3, but not receipt, I think you misread the issue.

[jeromevvb]

@aksdevac My Apologies, Indeed i misread the issue. I have the same issue also.

[nazarhussain]

@aksdevac I tried to reproduce it with the sample repo you provide. I tried version 1.2.11, 1.4.0 and 1.5.2 with MetaMask iOS app. To me it was the same behaviour on all the versions. The event transactionHash was triggered but receipt was not triggered with any of the versions. Can you please verify once again by clearing all cache that is it really working on 1.2.11 as you described in the issue.

[nazarhussain]

I found the problem. 😌

Its because of an assumption that if a provider specified an on handler it MUST support newBlockHeaders event as well. In case of @walletconnect/web3-provider that’s not the case. If this happens to @walletconnect/we3-provider it can happen to other providers as well. The relevant code was tried to fine tune in following PR as well PR-3517

I could not find any reference supporting this assumption. The EIP-1193 suggest that providers MUST be implementing connect, disconnect , chainChanged , accountsChanged and message but not forcing this for the support of subscriptions. e.g. We don't have support for subscriptions in the web3-providers-http. WalletConnect bridge provider supports few events but not the newBlockHeaders.

And there is no standard way to identify if a provider is supporting particular subscription. Unless we have one, I think we should not be relying on the subscriptions for this particular flow of transactions receipt and confirmation and alway use the pooling technique.

[nazarhussain]

@jdevcs @spacesailor24 While I was testing the fix, I observed that bandwidth usage was increased for the app, which is obvious while checking for receipt with polling technique this will occur. I also thought the increased bandwidth usage may hinder many apps. What you guys think on it?

[wafflemakr]

Was having the same issue with web3 v1.5 (getting txHash but not receipt). Downgraded to 1.2.11 and now I get receipt. Using "@walletconnect/web3-provider": "^1.6.5"

[xale76]

even with 1.6.5 my code remains stuck in await.
in example:
await dai.methods.approve(icoquantix_address,amnt).send({from:address,type:type});

[xale76]

hello the problem is not resolved. In metamask on iPhone, no callback is issued

[aporo001]

why close this issue. I am having the same issue in version 1.6.0

[xale76]

why close this issue. I am having the same issue in version 1.6.0
can you see the same problem as mine?
#4438 (comment)

[xale76]

@spacesailor24 so my problem is fixed in v1.6.1-rc.0?

[spacesailor24]

@spacesailor24 so my problem is fixed in v1.6.1-rc.0?

@xale76 It should be, please test it and let us know!

[xale76]

@spacesailor24 it seems to work! great

[xale76]

@spacesailor24 can I use this version or it's better to wait next official release?

[spacesailor24]

@spacesailor24 can I use this version or it's better to wait next official release?

@xale76 It's an untested version, the official release won't be until after this week, but if it solves a problem for you, then it's at your discretion. Keep in mind you'll have to hardcode the RC version in your package.json (as you already have), and will have to revert the change when the official release comes out

[natansevero]

I was facing the same problem. I was using the web3@1.5.1. But the problem was solved when I upgraded version to web3@1.6.1

[BigMadCode]

I am still getting this issue on 1.7.0
Literally with wallet connect I am able to send a transaction and metamask processes it successfully but I get nothing back. Sometimes metamask throws an error "Oops something went wrong" but the transaction was confirmed. Is this Metamask or web3?

[0xSzeth]

Bumping my web3 dependency to web3@1.7.3 fixed the issue for me