Failed to subscribe to new newBlockHeaders to confirm the transaction receipts when await on a tx

[miohtama]

This error is throw when you do await web3.eth.send().

Environment

• Trust wallet Android
• WalletConnect
• Angular 9

I am getting this error transaction has been broadcasted (probably with a transaction confirmation). The error is Trust Wallet specific, it does not happen with MetaMask for Mobile or MetaMask (desktop).

The error comes from somewhere from @walletconnect/web3-provider package.

However, the stacktrace is useless because of the minification. What would be a way to get source maps working with WalletConnect packages with ease?

Versions below.

├─┬ @walletconnect/web3-provider@1.0.0-beta.47
│ ├─┬ @walletconnect/browser@1.0.0-beta.47
│ │ ├─┬ @walletconnect/core@1.0.0-beta.47
│ │ │ ├── @walletconnect/types@1.0.0-beta.47 deduped
│ │ │ └── @walletconnect/utils@1.0.0-beta.47 deduped
│ │ ├── @walletconnect/types@1.0.0-beta.47 deduped
│ │ └─┬ @walletconnect/utils@1.0.0-beta.47
│ │   ├── @walletconnect/types@1.0.0-beta.47 deduped
│ ├─┬ @walletconnect/qrcode-modal@1.0.0-beta.47
│ ├── @walletconnect/types@1.0.0-beta.47```

[miohtama]

After enabling source maps, here is the failing function.

function normalizeBlock(block) {
  return {
    hash: block.hash,  /// <---- This line, no hash here
    parentHash: block.parentHash,
    sha3Uncles: block.sha3Uncles,
    miner: block.miner,
    stateRoot: block.stateRoot,
    transactionsRoot: block.transactionsRoot,
    receiptsRoot: block.receiptsRoot,
    logsBloom: block.logsBloom,
    difficulty: block.difficulty,
    number: block.number,
    gasLimit: block.gasLimit,
    gasUsed: block.gasUsed,
    nonce: block.nonce,
    mixHash: block.mixHash,
    timestamp: block.timestamp,
    extraData: block.extraData,
  }
}

Maybe this is related to the other error

zone-evergreen.js:171 Uncaught Error: Could not find block
    at index.js:58
    at index.js:137
    at index.js:196
    at once.js:12
    at p (eachOfLimit.js:61)
    at d (eachOfLimit.js:50)
    at onlyOnce.js:12
    at createAsyncMiddleware.js:20
    at index.js:29
    at g (index.js:29)

That happens in

  const self = this

  // trigger start
  self._ready.go()

  // on new block, request block body and emit as events
  self._blockTracker.on('latest', (blockNumber) => {
    // get block body
    self._getBlockByNumber(blockNumber, (err, block) => {
      if (err) {
        this.emit('error', err)
        return
      }
      if (!block) {
        this.emit('error', new Error("Could not find block"))
        return
      }
      const bufferBlock = toBufferBlock(block)
      // set current + emit "block" event
      self._setCurrentBlock(bufferBlock)
      // emit other events
      self.emit('rawBlock', block)
      self.emit('latest', block)
    })
  })```

[miohtama]

Related Uniswap/web3-react#63

[miohtama]

Also related Uniswap/web3-react#64

[miohtama]

Based on the analysis, it might be some sort of race condition. Trust Wallet returns transaction included in the block at the result of web3.eth.send() even before WalletConnect has information about this block. This is one theory.

[miohtama]

Confirming this also happens with MetaMask on Mobile, so seems to be WalletConnect issue itself.

[miohtama]

Ok, so I think I managed to the get actual stack trace and causes await to fail.

Error: Failed to subscribe to new newBlockHeaders to confirm the transaction receipts.

[miohtama]

Related:

web3/web3.js#951 (comment)

[miohtama]

Related coinbase/coinbase-wallet-sdk#19

[miohtama]

The reason why this happens with mainnet only is that after some wait node returns a null response, as described here: leapdao/leap-node#255

Mainnet is more clogged, so this is much more likely to happen with the mainnet as the transaction is not confirmed shortly.

[miohtama]

Also here is the reason why you might get both success and error response for the same transaction:

web3/web3.js#2726

When the await finishes, it gives one receipt. If you are subscribed to PromiEvent.on you might get another response. Depending on the timing, the race condition can give you either (success, failed) or (failed, success) tx receipt responses.

[miohtama]

Here is a mention that should be fixable in Web3.js 1.2.2

web3/web3.js#1423 (comment)

[miohtama]

Web3.js 1.2.2 release notes hint about parameters you could use to mitigate this issue:

https://github.com/ethereum/web3.js/releases/tag/v1.2.2

[miohtama]

Here is the actual logic what will happen:

https://github.com/ethereum/web3.js/blob/2a5c5cb740ee8962846ac9d5416e6b8cc2e7d95d/packages/web3-core-method/src/index.js#L534

After timing out the HTTP call, web3.js tries to build a WebSocket subscription to start another wait mode.

The error message is somewhat confusing, but when checking into web3.js internals that is even more scary.

[miohtama]

Opened an issue against web3.js

web3/web3.js#3498

[BrianValente]

I'm having the same problem, were you able to fix it? Also I'm getting this error randomly, did you noticed it too?:

Unhandled Promise Rejection: TypeError: null is not an object (evaluating 't.hash')

[miohtama]

It needs to be properly fixed in web3.js, but here is my workaround https://gist.github.com/miohtama/a91a5edabac6bf66de860a444fc13206#file-transaction-helper-component-ts-L326

[pedrouid]

Is this still an issue with latest (currently on v1.0.11)??

[FahdW]

@miohtama I have the same issue occurring. web3 + metamask has the tx coming back to early, but how do you manage the data that comes back? previously it use to run something else underlying and you could get the events back. Now you no longer can and you get just the tx and it's logs

[themeltdown]

@pedrouid so this issue is still on going, and the error is received randomly. After a transaction.
Using walletconnect web3 provider v.1.7.0 and web3js 1.6.1

Tx is made with walletconnect and mobile metamask.

[finessevanes]

Hey I'm the Developer Advocate at WalletConnect. @miohtama, @FahdW, @themeltdown, are you still experiencing this issue? If so, have you attempted to use v2?