Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
pszabop opened this issue Oct 9, 2017 · 8 comments · Fixed by #3109
Closed

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

pszabop opened this issue Oct 9, 2017 · 8 comments · Fixed by #3109
Assignees

Comments

@pszabop
Copy link

pszabop commented Oct 9, 2017

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
Copy link

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
Copy link
Author

pszabop commented Oct 9, 2017

@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
Copy link
Author

pszabop commented Oct 9, 2017

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
Copy link
Author

pszabop commented Oct 9, 2017

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
Copy link

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.

@nivida nivida self-assigned this Aug 9, 2018
@shivamsinha15
Copy link

+1

@nivida
Copy link
Contributor

nivida commented Oct 30, 2018

This issue will be solved in the next build 💪🏻

@nivida
Copy link
Contributor

nivida commented Nov 29, 2018

I fixed this in the PR #2000.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants