Closed arwer13 closed 1 year ago
Thanks for the detailed bug report!
I'd propose to consider:
- Keep all logs in
ReceiptAPI.events
, where the ones failed to decode are represented as raw stubs- Print the message "DEBUG: failed to decode log data for ..." as WARNING.
These are great suggestions to make it easier to debug in the future, really appreciate that!
I created the same exact event type locally, made a tx with pretty much the same-ish data, analyzed both the data from the my local test and the data on the Etherscan linked event and I found the one I had locally had the correct number of trailing zeroes whereas the one on Etherscan is truncated.
So I noticed the eth_abi
decoders have a kwarg for strict
which is defaulted to True that requires the correct trailing zeroes and such. So what I did in my linked PR (along with your other suggestions) is try again with strict=False
with a unique warning in this situation to mention that this was required.
Environment information
ape
and plugin versions:What went wrong?
Failed to decode a log with known ABI. See event number 136 in https://etherscan.io/tx/0xa4629245311d93a11cedb9143d8b7530057685b4b568a026bac194e162002c13#eventlog
Maybe the problem happens when there is a
string
event field.How can it be fixed?
I'd like to mention a few more details. The issue was discovered after I found
ReceiptAPI.events
lack of theNodeOperatorAdded
event. At first the events list was quite misleading, because I expected to see all the logs there. And to locate the problem I had to dive in the Ape sources.I'd propose to consider:
ReceiptAPI.events
, where the ones failed to decode are represented as raw stubs