decentraland / decentraland/decentraland-dapps
Wrongly marking a transaction as "reverted" when it didn't
- 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
Assessment
This issue has not been assessed yet.