What does the Web3 "BigNumber not a base 16 number Error" mean

Question

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?

Answer 1

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.

Answer 2

This is a reproducable bug in web3.js.

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

Answer 3

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.