-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Decoding events and fetching past events is failing with an UnhandledPromiseRejectionWarning: #992
Comments
This fixes the problem by appending a bunch of 0's to the end of the data
|
I believe the cause of the issue is a check on ethers.js/packages/abi/src.ts/coders/abstract-coder.ts Lines 163 to 172 in 9640e86
To recreate use this event which I've commented for ease of following const breakingLog = {
transactionIndex: 1,
blockNumber: 3886094,
transactionHash:
"0x813647d395204e300e70203a9349192e10bb3c9e0ab9041f27a383717c97d0ec",
address: "0x74f2b28994e9bd00A3B6CD1826Fd29AB76f840F9",
topics: [
"0xff628606f5860a17beddc73a7046379d2539e0f878cb934e43ce2c5150bc91a5",
"0x000000000000000000000000cf0adeeab9bfca0ea7663c10a49067fcebaa2368",
],
data:
"0x" +
// address token = "0x0000000000000000000000000000000000000000"
"0000000000000000000000000000000000000000000000000000000000000000" +
// uint256 amount = 1300000000000000000
"000000000000000000000000000000000000000000000000120a871cc0020000" +
// bytes32 homeTx = "0x20fe4c12ca16a0a2199d7c3f179921658a24715730d8bf903b3766bba3eea830"
"20fe4c12ca16a0a2199d7c3f179921658a24715730d8bf903b3766bba3eea830" +
// bytes data = "4C4316C7000000000000000000000000000000000000000000000000000000000000006B0000000000000000000000000000000000000000000000000000000000000064000000000000000000000000387871CF72C8CC81E3A945402B0E3A2A6C0ED38A000000000000000000000000000000000000000000000000120A871CC0020000"
// offset in the log domain to point to where the data is: 4*32 bytes = 128 bytes, 0x80 in hex
"0000000000000000000000000000000000000000000000000000000000000080" +
// Number of elements (bytes) in the bytes array = 4*32 + 4 = 132 bytes, 0x84 in hex
"0000000000000000000000000000000000000000000000000000000000000084" +
"4c4316c7" +
"000000000000000000000000000000000000000000000000000000000000006b" +
"0000000000000000000000000000000000000000000000000000000000000064" +
"000000000000000000000000387871cf72c8cc81e3a945402b0e3a2a6c0ed38a" +
"000000000000000000000000000000000000000000000000120a871cc0020000",
logIndex: 5,
blockHash:
"0xdb9c490c33bc0b92a68c405bc6601918922e0c935c979a012951fecda474f450",
};
// abiForeignGivethBridge in https://rinkeby.etherscan.io/address/0x74f2b28994e9bd00A3B6CD1826Fd29AB76f840F9#code
ethers.utils.Interface(abiForeignGivethBridge).parseLog(breakingLog) Why is that check necessary in this context? |
Is it possibly this is related to this issue? Are the invalid logs coming for Solidity 4.x where the function was marked as |
The above data you gave looks wrong (just by eye; I’m still in bed reading this ;)), but every slot should be 32 bytes long. The The old decided did not do this check, so it was possibly to overrun into subsequent data, luckily it got trimmed off. But it may be possible for wrong data to be emitted as a result. I need to do some research into this though. It is a known bug in Solidity though, and they fixed it in 5. I’m considering adding a recovery mode for bad events, but if you have some examples of transactions with these bad entries that would help. The biggest issue with trying to solve this is it produces content that cannot be earablished as an error or not. Content that is congruent (in length) to 0 mod 32 bytes is a success, anything congruent to 4 mod 32 is an error. With the old coder, it would emit data you expect to be an error (4 mod 32), which ethers will throw a CALL_EXCEPTION for, but for which the contract believed it was doing the correct thing. So if there was a way to allow a non-strict parsing, you would lose the ability to detect revert reasons. In fact, it would be non-deterministic; you may not detect an error when there was one and you may get data out when there was an error, with some non-trivial probability (off the top of my head this could happen as much as 3% of the time). I think. :) If I understand the issue correctly. :) |
@ricmoo The data of the example was pulled from this actual transaction https://rinkeby.etherscan.io/tx/0xa20e3db910d95a5a23692eef523bd6e98152d4759782e6097d3f6eaccf17ff46#eventlog logIndex 5. |
@dapplion yes, the bytes must be padded to be a multiple of 32 bytes. There is a known Solidity v4.x bug that events emitted from an external (public is fine) function in Solidity that dynamic objects are encoded incorrectly. If you look at line 1075 in the contract for the transaction you provided, the function is marked external and it is from an affected version of the compiler. This is a compiler bug which makes it very hard to work around. :( The work around for it can break correctly functioning contracts, which is the problem. We can possibly use a modified version of the coder (or pass a flag in) for events that allows looser checks, but which might allow corrupt data to be emitted and can certainly not be used for generating encoded data passed into solidity as that could result in completely corrupt execution. It’s a sticky sitch. :s |
Here is another link with more info: web3/web3.js#3544 |
After reading the referenced issues from June is there a roadmap to allow corrupted events to be parsed somehow? |
The above code sample throws the above mentioned error on ethers version 5.0.8. |
I got this question but not in events,it is just a function call.
gor error: @GriffGreen Please help me. |
Ane i use solidity v5.0 |
@Machael-lcg Can you provide an example transaction and the code you are using? |
Have been hoping around from a few ethereum libraries... but we are thinking that the ABI-decoder is the issue.
Previous issues
web3/web3.js#3671
Consensys/abi-decoder#56
are summarized below
It seems that the ConsenSys abi-decoder calls web3.js but in the end uses the ethers.js abi decoder... cause well.... you guys rock ;-)
System information
Geth version:
geth version 1.9.18-stable
OS & Version: Linux
Commit hash : (Infura and Aragon gateway)
Expected behavior
Decoding events/logs and fetching past events just works
Actual behavior
For years we were able to decode data for events and then about a week ago it just stopped working... now we get an error
Steps to reproduce the behavior
The decode function produces this error message on decoding data:
(node:55476) UnhandledPromiseRejectionWarning: Error: data out-of-bounds (length=164, offset=192, code=BUFFER_OVERRUN, version=abi/5.0.0-beta.153)
We modified the log data and filled it with zero value except for the part I needed and the code works as before.
It's the code that has been modified if you remove the part that modifies the log.data the error appears
https://github.com/Giveth/feathers-giveth/blob/b164131e588f640a8bd83136ad6c867fb7b6733b/scripts/utils/getHomeTxHash.js#L27-L55
This is the smart contract code and abi: https://rinkeby.etherscan.io/address/0xff9cd5140e79377feb23f6dfaf1f8b558c0fe621#code
And we tried to decode the log data of this transaction: https://rinkeby.etherscan.io/tx/0xa20e3db910d95a5a23692eef523bd6e98152d4759782e6097d3f6eaccf17ff46
Environment
Node v8.17.0
Web3 1.2.11
OS Linux and MacOS
This is the a sample code to regenerate the error:
The text was updated successfully, but these errors were encountered: