Closed Jannis closed 4 years ago
This seems reasonable, after this we should be more careful when making changes to the decoding logic, for example if we fix a bug to successfully decode something that was failing, we need to version because it's a breaking change.
This would be a boon for us at Synthetix. We emit events on a proxy contract and the underlying ABIs have shifted over time.
To clarify, only a very specific ABI change should be affected by this, which is when you call a function with the same name and parameters as the one in the subgraph's ABI, but the return type has changed.
If the name or input types change, we should already catch it and reverted
should be true.
Ah so in that case we shouldn't be impacted by it. It seemed we were running into this with different argument parameters but perhaps not; if I can repro it I will post here.
This seems to be a general issue, graph-node crash the whole subgraph when decoding fails.
Contract calls made with
try
handle assertion failures in contracts but they don't currently handle ABI decoding errors / ABI mismatches.For example, different contracts could implement a
name
function with different return types. A call likecurrently works with contracts that have a
name
function that returns a string, but will fail with contracts that have aname
function that returns e.g. abytes32
.try
exists not just to detect reverts (although that was its original purpose), but could also allow to test whether a method can be called on a contract at all. Cases that would be good to cover:One idea could be to add an
resultDecodingFailed
field similar toreverted
so you could do