24

Is there a known problem with parsing events containing strings in Truffle/Web3?

I'm using truffle with the following simple contract

contract Board
{
    string  foo;
    event Shout();
    event TextEvent(
        string  indexed text,
        uint timestamp
    );

    function shout(string _text)
    {
        foo=_text;
        Shout();
        TextEvent(_text,now);
    }

    function getFoo() returns(string){
        return foo;
    } 
}

When I call shout(_) foo is set correctly and a Shout event is triggered and I can listen to this without any problems.

  var board = Board.deployed();
  var shouts=board.Shout();
  shouts.watch(function(error, result){
    if (!error)
      console.log("shout",result);
  });

However when I watch for TextEvents with the following code

    var board = Board.deployed();
    var textEvent=board.TextEvent();
    textEvent.watch(function(error, result){
        console.log("callback");
        if (!error) console.log("shout",result);
    });

I get the following error which seems to be related to converting bytes32 into a string:

Uncaught BigNumber Error: new BigNumber() not a base 16 number:

So the question is how can you listen to events containing strings in Web3 without running into this error?

q9f
  • 32,913
  • 47
  • 156
  • 395
JackWinters
  • 3,413
  • 2
  • 17
  • 29
  • 1
    This appears to be a bug in web3. I get similar error when trying to return bytes from an event. Please raise an bug report in the following repo - https://github.com/ethereum/web3.js/issues – Hudson Jameson Mar 16 '16 at 21:09
  • 2
    Most likely because the parsing function has been passed a string with the "0x" at the beginning like "0x6c3c...". – BokkyPooBah Apr 16 '16 at 00:23

3 Answers3

14

I saw this when my blockchain wasn't fully synced. The contract was expecting a string to be returned, but since that string hadn't been set yet it was returning null, which would blow up on parsing.

I believe the same thing could happen when pointing to an address that doesn't actually implement that API. If the fallback function doesn't return a string then you'll have trouble parsing a string.

Just make sure your blockchain is synced, and you're pointing to the right account.

Steve Ellis
  • 1,357
  • 13
  • 21
  • 1
    This should be the accepted answer. This seems to happen if web3 (for example) tries to communicate with a contract which is not locally synced yet. – q9f Jun 30 '16 at 20:34
  • 2
    To add. I experienced this bug, because the ABI didn't correctly correspond to the contract. It expected a string, and thus threw an error. – Simon de la Rouviere Jul 31 '16 at 21:08
  • 1
    Also I'd like to point out that this can be caused by even slight modifications to the ABI. I got this error when had forgotten to update the client-side ABI so one part of code was expecting indexed fields in events, and the other one was not aware of them. This resulted in the new BigNumber() not a base 16 number error as well. – Santeri Paavolainen Nov 16 '18 at 12:38
9

This is a reproducable bug in web3.js.

ref. https://github.com/ethereum/web3.js/issues/434

q9f
  • 32,913
  • 47
  • 156
  • 395
5

From the Github issue:

The BigNumber() is not a base 16 number error can happen in many cases, yet the causes are not necessarily the same. I believe the original post's issue is with using Events that index on "string" types, which I'm running into as well. If my contract event marks a "string" type as "indexed", i get the same error. But if I restrict the "indexed" keyword to only "address" type, I'm fine. I'm trying to find documentation on what data types can be "indexed" in a contract event, but to no avail. My gut feeling is anything that can be parsed as a number (address, integers etc) might be OK. I don't think blockchain synching is the issue here.

So try removing any indexes on string fields in the event definition for now until they fix the bug.

k26dr
  • 861
  • 7
  • 12