decentraland / decentraland/decentraland-dapps

Wrongly marking a transaction as "reverted" when it didn't

Open
#81 0 comments 0 reactions 0 assignees View on GitHub
bug
Dominant language
TypeScript
Stars
116
Forks
52
Avg merge
18h 12m
Merged PRs (30d)
11

Description

Running some tests on Ropsten network, seems to happen when the network is slow, a transaction is being wrongly marked as Reverted status, when it didn't.

For example, tx hash [0x3cc266a2d188e26eed3033f34eafa8f7f583d40f09db76dfb8430557ddb23a66](https://ropsten.etherscan.io/tx/0x577477ce78b5309bc3fa37f7e5582515bebb5ed0468979dfdac8936f9a73d9e1), took about 1-2 mins to get up to 4 block confirmations.

When debugging this, I've noticed that in [txUtils.ts](https://github.com/decentraland/decentraland-dapps/blob/776b86012183890b5ccd7ddb23dcc01b92ffe5fb/src/modules/transaction/txUtils.ts), the response of `await eth.getTransaction(hash)`, was including a defined `blockNumber` value, which means it has been "received by the network" - ie. [not pending/queued/replaced](https://github.com/decentraland/decentraland-dapps/blob/776b86012183890b5ccd7ddb23dcc01b92ffe5fb/src/modules/transaction/txUtils.ts#L53). **But** later on, the call to `await eth.getTransactionReceipt(hash)` still returned `null` because the tx was still _pending_, ie. the block was not yet mined, according to web3 docs https://web3js.readthedocs.io/en/v1.2.0/web3-eth.html#gettransactionreceipt .

However in the [next conditional](https://github.com/decentraland/decentraland-dapps/blob/776b86012183890b5ccd7ddb23dcc01b92ffe5fb/src/modules/transaction/txUtils.ts#L86:L93), the if `receipt == null` considers it as being "reverted" which is not correct. By the docs, if the tx would've reverted, it would just have a status `false` (or `true` if confirmed).

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.