eth_getFilterChanges of eth_newBlockFilter returns empty log

[frozeman]

When i create a filter with eth_newBlockFilter:

{"jsonrpc":"2.0","method":"eth_newBlockFilter","params":["latest"],"id":2}

And a new block arrives i get:

[
    {
        "id": 35,
        "jsonrpc": "2.0",
        "result": [
            {
                "address": "0x0000000000000000000000000000000000000000",
                "topics": [],
                "data": "0x",
                "blockNumber": "0x0",
                "logIndex": "0x0",
                "blockHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
                "transactionHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
                "transactionIndex": "0x0"
            }
        ]
    }
]

The RPC specs state: "For filters created with eth_newBlockFilter log objects are [null]."
This means when you

• created the filter with "latest" it should return [null] when a new block was mined, otherwise [].
• create a filter with "pending" it should return [null] when a new pending transaction comes in, otherwise [].

[tgerring]

I have a fix prepared but am not certain that the output I'm getting is what is expected.

First I ran:

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newBlockFilter","params":["pending"],"id":73}' http://127.0.0.1:8545

Then

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getFilterChanges","params":["pending"],"id":73}' http://127.0.0.1:8545

Output is

{
    "id": 73,
    "jsonrpc": "2.0",
    "result": []
}

After my fix, output is instead

{
    "id": 73,
    "jsonrpc": "2.0",
    "result": [
        null
    ]
}

This doesn't quite match the examples you provided, so can you supply a minimum test case (using curl commands) and expected result?

[frozeman]

your test case is fine. though [null], should only come, if a pending transaction was incoming in the last time since you polled. Otherwise it should still be []

[frozeman]

When you call:

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getFilterChanges","params":["pending"],"id":73}' http://127.0.0.1:8545

multiple times, you should definitely get [] back, as there was likely no pending transaction add in between.

[frozeman]

btw. sometimes the blockfilter "latest" is fired multiple times on the same block. @obscuren do you know why this could be?

[tgerring]

The specification states the following functionality:

Array - Array of log objects, or an empty array (if nothing has changed since last poll).
For filters created with eth_newBlockFilter log objects are null.
For filters created with eth_newFilter logs are objects with following params:

This is exceedingly confusing, can we clean it up to make more sense?

@obscuren Logs are stored as map[int]*logFilter in XEth. Is there some natural meaning to the types of logFilters stored that can be checked when returned to match the above functionality?

[frozeman]

its actually clearly described imho, but the fact that the log object is null is confusing, yes.

null just means, "yes there was an update", but it doesn't show you what updated.

I will try to write it a bit more clear.

[frozeman]

I wrote up a proposal of how i think it should better work:
https://github.com/ethereum/wiki/wiki/newBlockFilter-Improvement-Proposal

Please have a look. Especially at the example. The described return value of block filters will be actual useful for developers, while the current ones are only limited useful.

[frozeman]

Actually this issue is solved when the newBlockFilter proposal is implemented. https://github.com/ethereum/wiki/wiki/newBlockFilter-Improvement-Proposal#new-proposal

[frozeman]

Fixed through #864