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

eth_newFilter returns malformed ids with trailing zeroes #58

Steffen93 opened this Issue Jan 23, 2018 · 5 comments


None yet
7 participants
Copy link

Steffen93 commented Jan 23, 2018

Expected Behavior

When a new filter is created using eth_newFilter, the ID returned should be formed correctly according to this description on how to encode quantities, i.e., no trailing zeroes like "0x03"

Current Behavior

The ID returned after filter creation contains leading zeroes like "0x03" instead of "0x3", also only accepting the same string when the filter changes are queried. So querying filter changes for "0x3" will result in the error message "FilterSubprovider - no filter with that id: 0x3". So, if the ID is stored as an integer and (de-)serialized before calls are made, the previous error occurs.


I stumbled upon the problem using the rust-web3 library and also opened an issue there which resulted in a temporary workaround. Nevertheless I think the root cause is here and it should be fixed.

My Environment

  • Version used: Ganache v1.0.2 / ganache-cli@6.0.3
  • Operating System and version: Ubuntu 16.04.3 LTS

This comment has been minimized.

Copy link

jasonadkison commented Feb 8, 2018

I'm experiencing the same issue using Ganache CLI v6.1.0-beta.0 (ganache-core: 2.1.0-beta.0)


This comment has been minimized.

Copy link

kvap commented May 11, 2018

The same issue in the return value from eth_getLogs, it looks like this:

[{"logIndex":"0x00","transactionIndex":"0x00", ...

This comment has been minimized.

Copy link

bh2smith commented Aug 13, 2018

Has anything been done regarding this issue?!

I am also getting back result from eth_getLogs with


which appears to be coming from

if(val.length % 2 != 0) {
val = "0" + val;

According to the ethereum wiki for JSON-RPC for allowed vs not allowed encoded QUANTITIES (including logIndex and transactionindex), the result dict should really be more like


Notice that the problem with this response lies within go-ethereum/common/hexutil/json.go at line 306

if len(input) > 1 && input[0] == '0' {
    return nil, ErrLeadingZero

Which throws a leading zero error for such response values


This comment has been minimized.

Copy link

bh2smith commented Jan 29, 2019

Now that this is closed, was there a change that solved it?


This comment has been minimized.

Copy link

eshaben commented Jan 29, 2019

@bh2smith, I'm sorry that I didn't respond with my findings before this issue was closed! It looks like this was fixed by changing the way we handled the hex encoding of the logIndex and transactionIndex values. The changes were made in this commit: d187a66. I validated the changes with the tests in this commit: 45301c2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment