PROBLEM

Ethereum users receive immediate responses for errors related to nonce or any issue that prevents a transaction from being forwarded to the network, thanks to the existence of the mempool/transaction pool.

On Hedera, we cannot raise these kinds of errors right away — we do so only at consensus time.

On the other hand, we do have custom errors related to throttles, which are new to Ethereum developers.

Both of these differences alter the usual EVM experience for users because:
• They will not receive an error immediately if the RPC has async transaction processing enabled
• When they query the transaction receipt, they may loop indefinitely as no receipt will ever appear

Given this, we have both a responsibility and a challenge: to provide as close to a 1:1 experience as possible with Ethereum.

Solution

1. Sync Processing Mode (async = false)

If the relay is in sync processing mode:
• It waits for consensus
• It can return consensus-time errors directly in the sendRawTransaction response

This has been implemented in : "Ensure errors from consensus node are not silently swallowed"
#4697

2. Async Processing Mode (async = true)

If the relay is in async mode:
• It does not wait for consensus
• It cannot return consensus-time errors in sendRawTransaction

Proposal: Introduce new logic in getTransactionReceipt that fails with a proper RPC error (instead of returning null) when we know the transaction has failed due to nonce issues or throttles. Use a custom RPC error code within the reserved range.º

-Review the error defintion proposal: -32003 Message = given error. 32003 is transaction rejected and the most meaningful

• Identify how to check if tx failed at consensus time in MN, and fail at rpc level. if it implies some extra MN calls, share with the team for discussion, and possible review with in MN
• Test with web3js, and ethers, to check if tx.wait and other scenarios are capturing the error