graphprotocol
Tuple array in signature handled incorrectly in codegen script
I'm currently trying to add an event handler for a specific event which uses a struct as a parameter, but the codegen script will only allow the signature to be specified as a generic tuple[] instead of the specific internal components of the tuple. This seems to be causing issues afterwards, since it never triggers the event handler, even though the event itself exists in the blockchain.
Here we can look the event up, it's the one with this topic0: 0x082d2a29e61e3d0508e5617570bed4c7c58ae73d4719b31052d8638812bc4c0c
The specific definition of this event in the ABI looks like this:
{
"anonymous": false,
"inputs": [
{
"indexed": true,
"internalType": "uint256",
"name": "id",
"type": "uint256"
},
{
"components": [
{
"internalType": "address",
"name": "to",
"type": "address"
},
{
"internalType": "uint256",
"name": "value",
"type": "uint256"
},
{
"internalType": "bytes",
"name": "data",
"type": "bytes"
}
],
"indexed": false,
"internalType": "struct Governor.Transaction[]",
"name": "transactions",
"type": "tuple[]"
}
],
"name": "NewProposal",
"type": "event"
}
And this is how it's defined in the solidity code:
struct Transaction {
address to;
uint256 value;
bytes data;
}
event NewProposal(uint256 indexed id, Transaction[] transactions);
At first I just used the signature that the codegen recommended, since it would not pass the checks if I didn't
After trying it that way, the subgraph itself only failed because the entities that were created on that event were being handled incorrectly, that is because that event had to handle the creation (with all the required fields present) and then other event would handle updates on those entities. Those updates were the ones causing issues, since the events that had to create those entities weren't being fired, but the entities were being created on the update events, with almost all the required fields left blank.
After that, I tried add a topic0 to the eventHandler definition on the subgraph.yaml, as suggested by @leoyvens, and now the error seems to make more sense:
It would seem like the codegen is incorrectly generating the event signature, which then leads to that event handler not being fired correctly because of a hash mismatch, since the keccak256 hash of the event signature is not the one found in etherscan.
