fromBlock: 0 defaults to latest, fromBlock: 1 works correctly in eth.getPastLogs

[pszabop]

fromBlock: 0 defaults to latest, fromBlock: 1 works correctly in eth.getPastLogs

I suspect somewhere in either web3.js or ethereumjs-testrpc there's a boolean check for fromBlock which evaluates to false if fromBlock is set to zero...

Repro:

1. create some logs
2. find logs starting at block 0. Only the latest transaction's logs show up.

return eth.getPastLogs({
    fromBlock: 0,
    toBlock: 'latest',
    address: this.contract.address,
    topics: topics,
  }).then(r => {
  // only the latest transaction's logs are in the result

1. find logs starting at block 1. All prior logs get returned as expected.

return eth.getPastLogs({
    fromBlock: 1,
    toBlock: 'latest',
    address: this.contract.address,
    topics: topics,
  }).then(r => {
  // all logs matching topics returned as expected.

[varsnotwars]

What happens when you pass in 0 as a string: "0". That would get around the coercion of 0, if that is what is happening.

[pszabop]

@varsnotwars passing in '0' doesn't find anything at all...

btw I'm on "web3-eth": "^1.0.0-beta.21" should I try upgrading?

[pszabop]

I believe I have likely tracked down at least one location that has this problem:

https://github.com/MetaMask/provider-engine/blob/c878e5ac19e061dc3de7f317f5ed4090b3fbd49c/subproviders/filters.js#L328

I shall file this bug there... but figuring out the dependency tree is still a work in progress...

[pszabop]

I'm not an expert in ethereum javascript dependency trees but it's likely that the provide-engine is the source of the bug. Searching my npm_module tree found the above to be the only likely source.

[brannondorsey]

This bug through me for a loop for quite a while. Until it's fixed, we should maybe update the new web3.js 1.0 docs to warn users of this unexpected behavior.

[shivamsinha15]

+1

[nivida]

This issue will be solved in the next build 💪🏻

[nivida]

I fixed this in the PR #2000.