Conversion from 'AssemblyScript' to 'Value' for source type 'Array<ethereum.Tuple>' is not supported - graph-cli 0.56.0

[0xMikado]

Which packages are impacted by your issue?

@graphprotocol/graph-cli

Describe the issue

Hello, it appears graph codegen still fails for an event/function with a Tuple[] structure.

It has been discussed a lot of times in different issues, with apparently a fix in some of the graph cli versions. You can see previous discussions on this here:

• issue#342
• issue#253
• pull#456

However, I still face this issue on the latest version (0.56.0).

Reproduction

no

Steps to Reproduce the Bug or Issue

Run graph add 0x0259119359Bf053ebF42C9807752de6bbb4925f3 You should get the following error: Error: Conversion from 'AssemblyScript' to 'Value' for source type 'Array<ethereum.Tuple>' is not supported

Expected behavior

To have graph add run properly.

Screenshots or Videos

No response

Platform

• OS: [macOS]
• NodeJS: [18.12.0]
• @graphprotocol/graph-cli: [0.56.0]
• @graphprotocol/graph-ts: [0.31.0],

Subgraph Manifest

No response

Subgraph GraphQL Schema

No response

Additional context

No response

[dimitrovmaksim]

I believe this happens when init or add try go generate an example entity based on an event that has a struct/list of structs as a parameter.

[azf20]

thanks @0xMikado and @dimitrovmaksim - do you think this is a regression or was this case never fixed? @saihaj do you have an idea where this might be tripping up?

[dimitrovmaksim]

I think this was never fixed. And i'm not sure it could be fixed for all contracts.

If the type of the event param is ethereum.Tuple / ethereum.Tuple[], it probably means it's a struct/array of structs. In newer ABIs (can't remember the solidity version where it was introduced), inputs have a property internalType that will hold the name of the struct. One way to fix this is to check if the input is actually a struct, then fetch the struct fields and their types from the components property and construct an Entity based on that. But this property internalType is not present in older abis

https://ethereum.stackexchange.com/questions/116913/fetching-internaltype-data-from-another-contract

For example this contract:

contract MyContract {
    struct MyStruct {
        uint256 myUint;
        string myString;
    }

    event MyEvent(MyStruct myStruct);

    function createMyStruct(uint256 _myUint, string memory _myString) public {
        MyStruct memory myStruct = MyStruct(_myUint, _myString);
        emit MyEvent(myStruct);
    }
}

will produce this ABI:

[
    {
        "anonymous": false,
        "inputs": [
            {
                "components": [
                    {
                        "internalType": "uint256",
                        "name": "myUint",
                        "type": "uint256"
                    },
                    {
                        "internalType": "string",
                        "name": "myString",
                        "type": "string"
                    }
                ],
                "indexed": false,
                "internalType": "struct MyContract.MyStruct",
                "name": "myStruct",
                "type": "tuple"
            }
        ],
        "name": "MyEvent",
        "type": "event"
    },
    {
        "inputs": [
            {
                "internalType": "uint256",
                "name": "_myUint",
                "type": "uint256"
            },
            {
                "internalType": "string",
                "name": "_myString",
                "type": "string"
            }
        ],
        "name": "createMyStruct",
        "outputs": [],
        "stateMutability": "nonpayable",
        "type": "function"
    }
]

what we want codegen to generate in the schema.graphq would be:

type MyEvent @entity {
    id: ID!
    myStruct: MyStruct!
}

type MyStruct @entity {
    id: ID!
    myUint: BigInt!
    myString: String!
}

EDIT

It seems internalType was added in Solidity 0.5.11

[azf20]

ok - in that case seems like a partial fix is the best possible option, and at least could provide better error messages in that case