Consider making error_message from /api/v1/contracts/results/ consistent and decoder friendly

[iron4548]

Problem

Typically with a Smart Contract execution error, I fetch the actual error from error_message value from /api/v1/contracts/results/transaction_id. Typically it starts with 0x and is greater than 10 characters long. A hex binary string.

I use this code to decode the error message to get a human friendly error message:

    const errorMsgHex = response.data.error_message;
    const errorMsgData = errorMsgHex.substr(10); 
    const errorMsgDecoded = Web3EthAbi.decodeLog([{
      name: 'error_message',
      type: 'string'
    }], errorMsgData, []);
    console.log(`Error message: ${errorMsgDecoded[0]}`);

This is another way to do it

    const errorMsgHex = response.data.error_message;
    const errorMsgData = errorMsgHex.substr(10); 
    const decoder = ethers.AbiCoder.defaultAbiCoder();
    const errorMsgDecoded = decoder.decode(['string'], `0x${errorMsgData}`)[0];

It works well when the error_message is a hex binary string.

However, from time to time I get a '0x' error message, and sometimes I get a human friendly error message such as 'INVALID_SOLIDITY_ADDRESS'. These error messages cause issues in the above code so I have to add workarounds to them, and I can imagine other devs have to do the same too.

Consider making the error_message variable format consistent (i.e. hex binary string only, or human readable format) so developers can work with one format.

Solution

Consider making the error_message data format consistent, i.e. binary hex string only with min 10 characters or human-readable. Hopefully at no performance cost.

For now I have a workaround (a few checks)

Alternatives

No response

[Nana-EC]

Thanks @iron4548 We're aware of this issue and it's a point of in-equivalence with the EVM that we plan to address. INVALID_SOLIDITY_ADDRESS is actually a specific network execution error. The initial architecture aimed to be more developer friendly and inform users of specific types of errors on the Hedera network. However, when experience through the EVM this creates the inconsistency you are experiencing.

We're looking into it and hope to resolve it. Thanks

[IvanKavaldzhiev]

Closing this issue, since we have a fix on the json-rpc relay side with this PR.

If we want to be ethereum compatible and have hex decoded revert reason - we should use the json-rpc-relay to fetch a given mirror-node infomration. Now the relay would always convert the reason to hex decoded string.

The mirror-node REST APIs themselves will continue to return ASCII-encoded values if such were received by the consensus nodes. Mirror-node's native functionality is not required to be ethereum equivalent, so we should keep this behaviour on their side.