Truffle: Truffle error when executing method call. Probably, error with event parsing.

Created on 13 Oct 2019  路  7Comments  路  Source: trufflesuite/truffle

  • [ no] I've asked for help in the Truffle Gitter before filing this issue.

Issue

When calling a contract method in my tests I'm getting Error: TypeError: Cannot read property 'toString' of null Given value: "null".

What I've found is when two different contracts have two events with the same signatures but different argument names, truffle parses the event using a wrong argument set. In my case the event is ERC721 Transfer:

event Transfer(address indexed from, address indexed to, uint256 indexed tokenId);

but truffle parses it as ERC20 Transfer:

event Transfer(address indexed from, address indexed to, uint256 amount);

Steps to Reproduce

Use the following set of contracts:

pragma solidity ^0.4.24;


contract MyERC20 {
  event Transfer(address indexed from, address indexed to, uint256 amount);

  function transferFrom(address _from, address _to, uint256 _amount) public {
    emit Transfer(_from, _to, _amount);
  }
}

contract MyERC721 {
  event Transfer(address indexed from, address indexed to, uint256 indexed tokenId);

  function transferFrom(address _from, address _to, uint256 _tokenId) public {
    emit Transfer(_from, _to, _tokenId);
  }
}


contract Foo is MyERC20 {
  MyERC721 public erc721Contract;

  constructor() public {
    erc721Contract = new MyERC721();
  }

  function myTransfer() public {
    erc721Contract.transferFrom(msg.sender, address(this), 1);
  }
}

and run this test:

const Foo = artifacts.require('Foo.sol');

contract('Foo test', accounts => {
  it('should execute #myTransfer()', async function() {
    const foo = await Foo.new();
    await foo.myTransfer();
  });
});

Expected Behavior

The test should pass without errors

Actual Results

The test fails with

  1) Contract: Foo test
       should execute #myTransfer():
     Error: TypeError: Cannot read property 'toString' of null Given value: "null"
      at Object.toBN (node_modules/web3-utils/src/utils.js:64:15)
      at _convertNumber (node_modules/@truffle/contract/lib/reformat.js:21:24)
      at abiSegment.forEach (node_modules/@truffle/contract/lib/reformat.js:77:33)
      at Array.forEach (<anonymous>)
      at Function.numbers (node_modules/@truffle/contract/lib/reformat.js:52:14)
      at logs.map.log (node_modules/@truffle/contract/lib/utils.js:78:38)
      at Array.map (<anonymous>)
      at Function.decodeLogs (node_modules/@truffle/contract/lib/utils.js:50:8)
      at Promise.receipt (node_modules/@truffle/contract/lib/handlers.js:98:28)
      at Promise.emit (node_modules/eventemitter3/index.js:181:35)
      at /Users/nikita/projects/tokenizable-erc721-locker/node_modules/web3-core-method/src/index.js:353:44
      at process._tickCallback (internal/process/next_tick.js:68:7)

Environment

  • Operating System:
  • Ethereum client: ganache-core
  • Solidity version: 0.4.26
  • Truffle version (truffle version): 5.0.40
  • node version (node --version): 10.15.3
  • npm version (npm --version): 6.4.1
help wanted

Most helpful comment

OK, put up PR #2474 as a temporary workaround for this (thanks to @eggplantzzz for figuring out a significant part of the problem). Again, a real fix will have to wait until the new decoder is ready.

All 7 comments

Yes, this is a problem with event decoding at the moment, which is currently done by an external library that doesn't know how to handle such cases of overlapping signature. I'm working on writing a new decoder that will be able to handle such cases, but it will be a while until it's fully ready and integrated into the rest of Truffle. In the meantime perhaps we can find a workaround -- perhaps just ignoring events that cause errors? Not a real solution, but a real solution will have to wait for the new decoder. Sorry about this!

OK, a simple workaround to this is to put a try/catch around event decoding and just to print a warning if event decoding fails, rather than letting that cause the test to fail. If anyone has time to do this, it'd be much appreciated. Otherwise, I'll probably get to it in a few weeks.

OK, started on this and turns out it's more complicated than that actually. Doing that just results in an error stemming from contract. Indeed, now that I look again, the originally reported error stems from contract -- it's not even the error I was thinking of! The null here is presumably coming from when I wrapped event decoding in contract in a try/catch as well a while back; I returned null on decoding failure. But now that null is causing problems, it seems. Will have to track this down...

Hm, nope -- it's not that null at all! The decoding itself isn't crashing. I'm having trouble finding what is...

OK, put up PR #2474 as a temporary workaround for this (thanks to @eggplantzzz for figuring out a significant part of the problem). Again, a real fix will have to wait until the new decoder is ready.

@haltman-at Thanks for this hotfix! Should we keep this ticket open until the new decoder?

No, I don't think that's necessary. I'll go ahead and close this. We can look at this again once the new decoder is ready.

Was this page helpful?
0 / 5 - 0 ratings