You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
When debugging this, I've noticed that in 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. 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, 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).
The text was updated successfully, but these errors were encountered:
tmilar
added a commit
to tmilar/decentraland-dapps
that referenced
this issue
Sep 1, 2020
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, took about 1-2 mins to get up to 4 block confirmations.
When debugging this, I've noticed that in txUtils.ts, the response of
await eth.getTransaction(hash)
, was including a definedblockNumber
value, which means it has been "received by the network" - ie. not pending/queued/replaced. But later on, the call toawait eth.getTransactionReceipt(hash)
still returnednull
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, 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 statusfalse
(ortrue
if confirmed).The text was updated successfully, but these errors were encountered: