Some ABIs are not deserializable in Golang

[arnaudbriche]

When working in the parquet dump in golang, trying to extract all the ABIs, I've got the following error:

unsupported arg type: Witnet.RadonReducerOpcodes

The message relates to the following ABI:

{
    "name": "encode", 
    "type": "function", 
    "inputs": [
        {
            "name": "reducer", 
            "type": "tuple", 
            "components": [
                {
                    "name": "opcode", 
                    "type": "Witnet.RadonReducerOpcodes", 
                    "internalType": "enum Witnet.RadonReducerOpcodes"
                }, 
                {
                    "name": "filters", 
                    "type": "tuple[]", 
                    "components": [
                        {
                            "name": "opcode", 
                            "type": "Witnet.RadonFilterOpcodes", 
                            "internalType": "enum Witnet.RadonFilterOpcodes"
                        },
                        {
                            "name": "args", 
                            "type": "bytes", 
                            "internalType": "bytes"
                        }
                    ], 
                    "internalType": "struct Witnet.RadonFilter[]"
                }
            ], 
            "internalType": "struct Witnet.RadonReducer"
        }
    ], 
    "outputs": [
        {
            "name": "bytecode", 
            "type": "bytes", 
            "internalType": "bytes"
        }
    ], 
    "stateMutability": "pure"
}

Looks like for enum arguments, the type field should be an int, not Witnet.RadonFilterOpcodes.

[kuzdogan]

Thanks for the report!

Assuming this is from the compiled_contracts table, could you please share the id of the row?

[arnaudbriche]

This is indeed from compiled_contracts. The row id is 18fd8e96-9715-4037-a736-d3b3b91297cd

[kuzdogan]

I was able to reproduce the ABI by recompiling using the data from that row. So it's not wrongly written by the verifier (blockscout). I'm checking if this is a problem in Solidity

[kuzdogan]

Hey it turns out this is expected in Solidity. The contract in question is a library and non-storage enums for libraries have indeed complex types. I've opened a PR to have this note added in docs: ethereum/solidity#15301

Basically a workaround would be to hard code a uint8 type for enums. See ethereum/solidity#9278 (comment)