minimal changes to allow for custom error decoding

[joseluu]

What was wrong?

In case of reverting in a smart contract using the "custom error" solidity construct available since solidity 0.8.4 (https://blog.soliditylang.org/2021/04/21/custom-errors/) , the details of the error were not available to the python application code

Related to Issue #
#2793
#2336

How was it fixed?

defining a new type of exception: ContractCustomError
raising this exception along with the data allows the application code to take it into account

example code that can be used by an application to decode a failed tx_hash for a contract whose abi is in variable DT_abi:

from eth_utils.abi import function_abi_to_4byte_selector, collapse_if_tuple

def decode_custom_error(contract_abi, error_data):
    for error in [abi for abi in contract_abi if abi["type"] == "error"]:
        # Get error signature components
        name = error["name"]
        data_types = [collapse_if_tuple(abi_input) for abi_input in error.get("inputs", [])]
        error_signature_hex = function_abi_to_4byte_selector(error).hex()
        # Find match signature from error_data
        if error_signature_hex.casefold() == str(error_data)[2:10].casefold():
            params = ','.join([str(x) for x in w3.codec.decode(data_types,bytes.fromhex(str(error_data)[10:]))])
            decoded = "%s(%s)" % (name , str(params))
            return decoded
    return None #try other contracts until result is not None since error may be raised from another called contract 

def diagnose_error_if_needed(receipt):
    if receipt.status != 1:
        tx = w3.eth.get_transaction(receipt.transactionHash)
        # build a new transaction to replay:
        replay_tx = {
            'to': tx['to'],
            'from': tx['from'],
            'value': tx['value'],
            'data': tx['input'],
        }
        # replay the transaction locally:
        w3.eth.call(replay_tx, tx.blockNumber - 1)

try:
    diagnose_error_if_needed(w3.eth.waitForTransactionReceipt(tx_hash))
except web3.exceptions.ContractCustomError as e:
    print ('Custom Error: %s' % e)
    print (decode_custom_error(DT_abi,str(e)))
except web3.exceptions.ContractLogicError as e:
    print ('Logic Error: %s' % e)

Todo:

• Add entry to the release notes

Cute Animal Picture

[kclowes]

Thanks for the PR @joseluu! We are focused on getting v6 stable out right now, so we don't have the bandwidth to review right now but please ping me if you haven't heard anything in ~2 weeks!

[joseluu]

@kclowes gentle reminder

[kclowes]

Thank you @joseluu! I started looking at this again. We'll need a test before we merge. I think the best thing to do is add a custom error to the existing revert contract. The source can be found under web3/_utils/contract_sources/RevertContract.sol, and then you'll need to recompile the contract, and put the bytecode and new ABI in web3/_utils/contract_sources/contract_data/revert_contract.py. Then some tests can be added in web3/_utils/module_testing/eth_module.py, similar to the test_eth_call_revert_with_msg/test_eth_call_revert_without_msg tests in that file. Let me know if you want me to take over, or if you have any questions! Thanks again!

[Shchepetov]

Hoping this PR can be merged soon
@joseluu Let me know if there's anything I can do to help

[kclowes]

@Shchepetov - does this PR fix your issue? As in - are you trying to get the raw data from a custom error revert? Or just a regular one?

@fselmo - would love to get your eyes/opinions here when you get a chance!

[kclowes]

I cherry-picked these commits to a new branch - #2916 - that I made (and therefore have CI permissions on), and CI is passing there.

[joseluu]

Thanks @kclowes for filling-in the test requirements, I have had little time recently to devote for this.

@fselmo : interpreting the error using the current contract ABI is certainly an improvement, it will ease simple cases where the error is raised by the contract itself and this will help a lot debug cases where one needs the extra information. However, in the general case, the error may be raised by another contract down the call chain, in which case the unformatted error should be passed as it is now for the application code to deal with it.

[kclowes]

Thanks @joseluu!

Thanks @kclowes for filling-in the test requirements, I have had little time recently to devote for this.

No problem! Thanks for getting it rolling.

However, in the general case, the error may be raised by another contract down the call chain, in which case the unformatted error should be passed as it is now for the application code to deal with it.

Thanks for this info. It sounds like the ideal case is a option (maybe a flag passed to call) that can switch between retrieving the raw error and the decoded error. I'm going to merge this as-is, and I'll add an issue to figure out a nice way to do that in a separate PR.

edit: there are already a couple issues to track, I don't think I need to add yet another :)

[kclowes]

CI is passing on #2916, so this is okay to merge!