decoder issue with 0x

[cellog]

I am seeing an error when parsing a transactionReceipt log

The error is Error: insufficient data for uint256 type (arg="_tokenId", coderType="uint256", value="0x", version=4.0.27)

I noticed the transaction:

has 3 logs, the first has this form:

So it looks like the decoder is not handling a valid data type returned from ganache. I have also seen this value returned from transaction receipts in the wild.

[ricmoo]

What is the ABI you are parsing?

[cellog]

so fast!

https://github.com/unlock-protocol/unlock/blob/master/unlock-js/src/abis.js#L384

[cellog]

We're still on 4.0.27 obviously... If this fix makes it in, I will upgrade to the latest

[ricmoo]

The last example you give certainly has an invalid data for Transfer... The data is “0x”, but it should be the 32 byte (64 nibble) token id.

Can you include an example log (pasted text, not an image, so I can copy paste :)) that doesn’t work?

[ricmoo]

(my first guess is that you either need to add “indexed” to tokenId in your ABI or remove it from your event declaration in the Solidity, which ever makes sense for your case, i.e. ERC-20 vs ERC-721)

[cellog]

confirmed: the script that generates the ABI is not pulling the indexed property out properly. Thanks for the help!

[cellog]

Actually, I see this: 'event Transfer (address indexed _from,address indexed _to,uint256 indexed _tokenId)'

[cellog]

{
 transactionIndex: 0,
 blockHash: "0x9d8fd1e7ae89294b37c4cb76376659972fa20023009d00354d997d74f7985731",
 blockNumber: 18231,
 data: "0x",
 logIndex: 0,
 transactionHash: "0x4086c613b943dd8dc53e68abd96b57deeb2d7dc5062f7354cd287946503880d0",
 address: "0x8276A24C03B7ff9307c5bb9c0f31aa60d284375f",
 topics: [
  "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",
  "0x0000000000000000000000000000000000000000000000000000000000000000",
  "0x000000000000000000000000a62a4e71336526b7e52b2c461076125c9f14a2c8", 
  "0x0000000000000000000000000000000000000000000000000000000000000001",
 ],
 transactionLogIndex: 0
}

[ricmoo]

Can you provide a log (only the data and topics are necessary) that is not being parsed?

[cellog]

I believe that is the log in #559 (comment), none of the others have data of '0x'

[cellog]

If I'm reading https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_getfilterchanges right, the data field should be 0x for an event where all the fields are indexed?

[ricmoo]

That is correct, and in the log you provided it is. And you are saying it isn’t parsing when you use the signature “event Transfer(address indexed from, address indexed to, uint indexed tokenId)”? What is the error you get?

[cellog]

Error: insufficient data for uint256 type (arg="_tokenId", coderType="uint256", value="0x", version=4.0.27)

I traced into ethers.min.js, and it appears this happens because it is looking at 0x and seeing that it has enough digits to fill uint256, which of course it doesn't.

[cellog]

I'm at your service for debugging this one

[ricmoo]

Right, which means the ABI it is using is incorrect. It will only look at data in the event the parameter is not indexed.

This works fine for me:

let data = "0x";
let topics = [
  '0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef',
  '0x0000000000000000000000000000000000000000000000000000000000000000',
  '0x000000000000000000000000a62a4e71336526b7e52b2c461076125c9f14a2c8',
  '0x0000000000000000000000000000000000000000000000000000000000000001'
];
let iface = new ethers.utils.Interface([ "event Transfer(address indexed from, address indexed to, uint indexed tokenId)" ]);
iface.parseLog({ data, topics });

/* Result:
_LogDescription {
  decode: [Function],
  name: 'Transfer',
  signature: 'Transfer(address,address,uint256)',
  topic:
   '0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef',
  values:
   Result {
     '0': '0x0000000000000000000000000000000000000000',
     '1': '0xA62a4e71336526b7E52B2C461076125C9F14a2c8',
     '2': BigNumber { _hex: '0x01' },
     from: '0x0000000000000000000000000000000000000000',
     to: '0xA62a4e71336526b7E52B2C461076125C9F14a2c8',
     tokenId: BigNumber { _hex: '0x01' },
     length: 3 } }
*/

So, I'm pretty sure it's just the ABI you are using is not matching the Solidity you are calling... :s

[cellog]

ok, I'll keep digging and report back when I find what is going on

[ricmoo]

You can try printing out your contract.interface, and make sure it is what you expect it to be. Make sure the interface.abi[WHATEVER_INDEX].inputs are all indexed...

If you are using truffle or some tools like that, make sure you try a clean build, sometimes it doesn't update artifacts correctly.

[cellog]

the plot thickens: that wasn't the log that was failing! It was this one:

{
 address: "0x591AD9066603f5499d12fF4bC207e2f577448c46",
 blockHash: "0x9d8fd1e7ae89294b37c4cb76376659972fa20023009d00354d997d74f7985731",
 blockNumber: 18231,
 data: "0x0000000000000000000000000000000000000000000000000de0b6b3a7640000",
 logIndex: 1,
 topics: [
  "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef", 
  "0x000000000000000000000000e29ec42f0b620b1c9a716f79a02e9dc5a5f5f98a", 
  "0x0000000000000000000000008276a24c03b7ff9307c5bb9c0f31aa60d284375f"
 ],
 transactionHash: "0x4086c613b943dd8dc53e68abd96b57deeb2d7dc5062f7354cd287946503880d0",
 transactionIndex: 0,
 transactionLogIndex: 1,
}

[cellog]

and look at that, the tokenid is missing!! I think we found the bug, it may be in the smart contract after all

[cellog]

OK! I just talked to our smart contract dev for a bit, and I finally understand what is going on. Our ERC721 contract is emitting the first event. But because this transaction is using DAI to do the actual purchase, the ERC20 contract is emitting the 2nd event (and the address field is the key). Our code does not check the address before passing in the ABI to parse the log, and so is incorrectly passing in the ERC721 abi to parse the ERC20 event.

Thanks for the help looking into this, it's definitely a bug on our side, ethers is fabulous, as always :)