Receipts for failed transactions

[tmcgroul]

Why receipts aren't available for failed transactions? For example:

curl -s -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","params":["0x60daafb24c3c573c803065cc9375da05660ce08b76ea2d5139261973740f737e"],"id":1}' -H "Content-Type:application/json" https://evmos-evm.publicnode.com

{"jsonrpc":"2.0","id":1,"result":null}

Other evm-compatible networks (ethereum, binance, etc) response receipts even if transactions are failed.
So my question - is it expected behavior? Will it be fixed in the future or kept as it is?

[VictorTrustyDev]

I don't see this transaction on-chain https://escan.live/tx/0x60daafb24c3c573c803065cc9375da05660ce08b76ea2d5139261973740f737e

I take another failed tx: https://escan.live/tx/0xda7e3ea4cc8f66c9b0d5ff6a7b043ad75a49071eda330bdddc52662d13ac4fd1

I called it and I got result:

curl -s -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","params":["0xda7e3ea4cc8f66c9b0d5ff6a7b043ad75a49071eda330bdddc52662d13ac4fd1"],"id":1}' -H "Content-Type:application/json" https://evmos-evm.publicnode.com

{
    "jsonrpc": "2.0",
    "id": 1,
    "result": {
        "blockHash": "0x92fa7289254c9259015b9991091d2c4d36073312076c6be23c03b45c7b6f694b",
        "blockNumber": "0xef6d7d",
        "contractAddress": null,
        "cumulativeGasUsed": "0x144ff0",
        "from": "0x6069be68577b66d8e1e7ab23f7155b016917ae91",
        "gasUsed": "0xa27f8",
        "logs": [],
        "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
        "status": "0x0", // status 0x0 means failed
        "to": "0x3b41454cb7858b6d0535e61bae9362af0151cc2d",
        "transactionHash": "0xda7e3ea4cc8f66c9b0d5ff6a7b043ad75a49071eda330bdddc52662d13ac4fd1",
        "transactionIndex": "0x1",
        "type": "0x0"
    }
}

[tmcgroul]

thanks for the quick response! please check this tx - https://escan.live/tx/0xe3791459cbcdd22536ef37cf0cc326ad3998a98d09cfe3dad760d36387bcc2fc

curl -s -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","params":["0xe3791459cbcdd22536ef37cf0cc326ad3998a98d09cfe3dad760d36387bcc2fc"],"id":1}' -H "Content-Type:application/json" https://evmos-evm.publicnode.com
{"jsonrpc":"2.0","id":1,"result":null}

[VictorTrustyDev]

alright, let's wait for Evmos core team's members take a took at this.

The tx failed with reason: out of gas in location: block gas meter; gasWanted: 1000000, gasUsed: 588495: out of gas

[tmcgroul]

hi @VictorTrustyDev
has core team commented the issue?

[VictorTrustyDev]

@tmcgroul same as you, I'm waiting

[luchenqun]

I'm not an evmos core team's member but I know the cause of this problem. The detailed reasons can be found in a PR I mentioned #1801 .

If there is too much content in RP, let me summarize: all evm type transactions will eventually be converted into a cosmos type transaction for execution, so whether it is successful or failed, there must be a cosmos type transaction on the chain. To query the evm receipt, the cosmos type transactions existing on that chain are recombined into an evm transaction receipt and returned to the user. The problem lies here, the chain will filter the receipt information, and only transactions that meet the conditions will be returned to the user. See this part of the code:

evmos/rpc/types/utils.go

Lines 279 to 283 in 31a4384

	// TxSucessOrExpectedFailure returns true if the transaction was successful
	// or if it failed with an ExceedBlockGasLimit error or TxStateDBCommitError error
	func TxSucessOrExpectedFailure(res *abci.ResponseDeliverTx) bool {
	return res.Code == 0 || TxExceedBlockGasLimit(res) || TxStateDBCommitError(res)
	}

If this function returns true directly, then you can check the evm transaction receipt. But I don't know why the evmos team filters this. @fedekunze Can you answer this question?

@tmcgroul
For example, for your transaction, there is actually a cosmos type transaction, see the link: https://www.mintscan.io/evmos/tx/96FD8D4D84C01C42B70E15E2BF8789791038E71A241F48BB3D4664ACB568DEC1?height=15690858

Overall, this is a bug. If I know what you did to trigger this bug(for example, which contract was called and the code of the contract), I can submit a PR to fix it.

[VictorTrustyDev]

If I remember correctly.
TxExceedBlockGasLimit is because Tx still success in EVM apply message but will be marked as failed if excess block gas limit.

[luchenqun]

If I remember correctly.
TxExceedBlockGasLimit is because Tx still success in EVM apply message but will be marked as failed if excess block gas limit.

Yes, you are right!

[luchenqun]

Why receipts aren't available for failed transactions? For example:

curl -s -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","params":["0x60daafb24c3c573c803065cc9375da05660ce08b76ea2d5139261973740f737e"],"id":1}' -H "Content-Type:application/json" https://evmos-evm.publicnode.com

{"jsonrpc":"2.0","id":1,"result":null}

Other evm-compatible networks (ethereum, binance, etc) response receipts even if transactions are failed. So my question - is it expected behavior? Will it be fixed in the future or kept as it is?

I've found the open source code for your calling contract: https://www.escan.live/address/0x720035b1417f9f9dea4097b578d30c373cd3dd04 and I'll try to fix it.

[luchenqun]

The reason for this problem has been found. It is because when you execute this transaction, your gasPrice is less than baseFee, so when DeliverTx an error is returned during the AnteHandle stage, resulting in the evm virtual machine not being able to execute this transaction at all.

But what is confusing is that this transaction should be checked out during the CheckTx stage and should not be put into the mempool. However, this error was reported after your transaction reached DeliverTx. It is possible that the previous evmos version did not check this error during the CheckTx stage.

[luchenqun]

It's all clear to me.
The information in block 15690857 is as follows:

Block 15690857
baseFeePerGas": 22187500000,
"gasLimit":40000000,
"gasUsed":34318622

The information in block 15690858 is as follows:

Block 15690858
"baseFeePerGas":28932117820,
"gasLimit":40000000,
"gasUsed":271310,

We see that the gasUsed of block 15690857 exceeds 50% of gasLimit, which means the baseFee increases. That is, the baseFee of block 15690858 increases from 22187500000 of block 15690857 to 28932117820. You should have sent the transaction to the mempool in block 15690857. At this time, because your baseFee is 27715925175, which is greater than the baseFee of block 15690857, which is 22187500000, you tx can successfully enter the mempool at this time. However, when the transaction was execut in block 15690858, the baseFee was lower than the baseFee of block 15690858, causing the transaction to fail.

[tmcgroul]

thank you for the investigation! actually it's not my transaction. i'm trying to index evmos chain and my indexing tool expect receipts to be availabe for every transaction

[luchenqun]

There is currently no solution after analysis and more time will be needed to resolve this issue.