eth_getBlockByNumber("pending", "false") returns null for block number

[peterbitfly]

I'm running:

• Which Parity version?: 1.11.1
• Which operating system?: Linux
• How installed?: binaries
• Are you fully synchronized?: yes
• Which network are you connected to?: ethereum
• Did you try to restart the node?: yes

Parity versions < 1.11.1 return the actual number of the pending block in the eth_getBlockByNumber("pending", "false") call, while parity version 1.11.1 returns "null" as pending block number. In order to not break backwards compatibility the call should return again the correct block number of the pending block. I assume the change is related to the new tx queue module.

[dvdplm]

Thank you for the report. I think that the pending option is deprecated, but there seems to be a bug around this and it shouldn't return null. Investigating!

[dvdplm]

There has been plenty of activity in this area lately and I'm not sure exactly if this is a bug or intentional.

The docs for eth_getBlockByNumber say that the call returns "A block object, or null when no block was found", so it seems to me that the behavior of the normal client on master is correct, and that 1.10 and the light client on master is wrong. The light client from master prints a message \Pending` is deprecated and may be removed in future versions. Falling back to `Latest`` but responds with this:

$ curl --data '{"method":"eth_getBlockByNumber","params":["pending", false],"id":1,"jsonrpc":"2.0"}' -H "Content-Type: application/json" -X POST localhost:8545
{"jsonrpc":"2.0","result":{"author":"0xb29…","difficulty":"0xb225a141ca63a","extraData":"0x73656f31","gasLimit":"0x7a121d","gasUsed":"0x7a0417","hash":"0x4d7f183b05cfa2767c6af0a84136e070b38aebb30baebe4eb80931641cfb9a01","logsBloom":"0x000328210280011001601044010201501840d00001120002002221020221c020c80000100004320a4014480800400800020811400008800180098804090000080040080803010001401440084004005010411021802c00080080204000000002000000000e420c000c02414e02080808210002104801a0488c052111102002002020880441300070404460808241c800012398b0004052b60a020004004180e088400020005030150240033910c4c800028008090180045002438040002001000c01000288a000800010003008012010040980018060000800002008220c21108000338084028c300100040c0000a40c01b500040a0004c05120100000002400","miner":"0xb2930b35844a230f00e51431acae96fe543a0347","mixHash":"0x1027e261561dc9cc9c8a47ce76cc993f9740143ee3a9c3f4255f3282c791e2c1","nonce":"0x7a320d001252ee02","number":"0x567f01","parentHash":"0x1f187383e5ed477d786b586d85287ea99bff95825a6767a8c5839fce40d0bca2","receiptsRoot":"0x77e9ac07b8a9f00156c869779e526300688104a65443b214dadbff8eed2d1384","sealFields":["0xa01027e261561dc9cc9c8a47ce76cc993f9740143ee3a9c3f4255f3282c791e2c1","0x887a320d001252ee02"],"sha3Uncles":"0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347","size":"0x773c","stateRoot":"0xc995a5aff754c9074974932f4bd5512cbcede4b894279b47bb7bfffd5530abf1","timestamp":"0x5b06adfc","totalDifficulty":"0xed1bb9981b3f6f1b09","transactions":["0xddf9e9e47 … …],"transactionsRoot":"0x4af111685082b7c4d1cafa003696cd21f673436ed43b5b20622e9da8980f730a","uncles":[]},"id":1}

I think we should fix the behavior on the light client: print a deprecation notice and return null. But on the other hand there's this that seem to imply it should not return null (but set several fields to null).

The normal client from master prints no warning and sometimes responds with:

$ curl --data '{"method":"eth_getBlockByNumber","params":["pending", false],"id":1,"jsonrpc":"2.0"}' -H "Content-Type: application/json" -X POST localhost:8545
{"jsonrpc":"2.0","result":{"author":"0x72…","difficulty":"0xaf37291b60a99","extraData":"0xdd83010c00865061726974798e312e32382e302d6e696768746c79826d61","gasLimit":"0x79f39e","gasUsed":"0x0","hash":null,"logsBloom":null,"miner":"0x723b85cfd78944dda92a4d718cfce7e36d873723","number":null,"parentHash":"0x18192309cf70ad93f8686a191fdfd6d2f71510a84c936ac7c7ec99da95cf1981","receiptsRoot":"0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421","sealFields":[],"sha3Uncles":"0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347","size":"0x1fa","stateRoot":"0x7d1a4e70a4f0b9189dd340e95783e02547b0f57867a72c3e73a1943a895e0fba","timestamp":"0x5b06ae73","totalDifficulty":"0xec3a52ba8af4cf9ea9","transactions":[],"transactionsRoot":"0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421","uncles":[]},"id":1}

…, but once the node is sync'd I see the same thing as the reporter is seeing: {"jsonrpc":"2.0","result":null,"id":1}

On 1.10, both the light client and the normal client return:

{"jsonrpc":"2.0","result":{"author":"0xea67…","difficulty":"0xb1f8fd05c6dbc","extraData":"0x65746865726d696e652d65753133","gasLimit":"0x7a121d","gasUsed":"0x79c6dc","hash":"0xa4c673c84d7273208d86e2d23b7c233f8ead518ad3c8412fd9b3c53d22fd7a60","logsBloom":"0x8802040008a2b418000483200882400100441202084218062000061812200000904840002d008504000118230b44040482224a012b109e800100c2840428012004400080a10883402410d00800804082444821141c50008000028210000007140401006802080000100108330000082104de30210802060100040058102c0b42a8521004416422340000000010240040840998005420003014023280208024002e010020080000009403020052120001008008010090c9a00850c4402800010a1000100204c041022012840040812000000600015848280a2000400a066020804410a52209b00202040001044ae083a402122032401200400021040431804019","miner":"0xea674fdde714fd979de3edf0f56aa9716b898ec8","mixHash":"0xf3e8953467338daf437b637e9699faaae7e621946e4a8b522fa8ab8301094ae1","nonce":"0x8492b489a67eda29","number":"0x567f11","parentHash":"0xa4b625067d1c61414e2ce2ee34b0e33952db4faba39325e7eb1fa3fddedfea86","receiptsRoot":"0xa58ca9521d5e143799c69875b87612a0d86bfc6d0a5020550f065813e2743eea","sealFields":["0xa0f3e8953467338daf437b637e9699faaae7e621946e4a8b522fa8ab8301094ae1","0x888492b489a67eda29"],"sha3Uncles":"0x203c46a2651f0b58ea53405fb8cc8b8849bb01d8293fb7f23a766205a11937e9","size":"0x7d1d","stateRoot":"0x654ba4a8a985f12f8290f191d82615396bbfb91ecf694c7bb813008a285f0447","timestamp":"0x5b06aeeb","totalDifficulty":"0xed1c6b81dd44b85663","transactions":["0x5e980d94ae… … ],"transactionsRoot":"0x1549d517a116e0bd4295e44a37aee85589311eca5a0b6c9112077e5767d10d2e","uncles":["0x6eb9317bea63b3f91ac68c07826f51207a1b1f7f0048f2b45dbc7aa7b228c699"]},"id":1}

/cc @tomusdrw @sorpaas do you have any input here?

[tomusdrw]

Pending block is never available on light client and might not be available on full node as well (if you are not force-sealing).
IMHO If pending block is available some fields should be set to null as per #8028, otherwise the query should return null.
But for historical reasons we fallback to latest block if pending is not available (some dapps pending block being always present).

The current strategy imho should be:

• Print notice that pending might not be available in future and fallback to latest for both light and full node (if n/a)
• In some future version: extend pending warning also on full nodes WITH pending block, stating that: "you're dapp may break on light clients, read more >here<"; possibly start a discussion on that topic on dapp devs reddit
• Later start returning null for pending block if it's not available.

Not sure if that's a viable strategy though, would be awesome to discuss some of that stuff during core calls (also see #5014)

[atlanticcrypto]

Hello,

Experiencing this issue as well. Upgrading 1.8.11 to 1.11.1 yields the same RPC response. Same db, and as soon as I roll back to 1.8.11 it works correctly again.

More than an annoyance, this is going to break every open source eth pool out there and delay upgrading to 1.11.x.

EDIT: Looks like this might be resolved by the nightly release? Will the deprecation warning slow response time?

[dvdplm]

Looks like this might be resolved by the nightly release?

This PR does not affect the recent change where the number member of the block is set to null for pending blocks. Instead it ensures that the light and full client behave the same (see PR description for details).

The question of nulling fields is a thorny one: respect the spec or avoid breaking other people's code. Can you help us understand better what it is you're doing that requires the number to be present?

Will the deprecation warning slow response time?

No, I do not expect any performance impact at all. :)

[atlanticcrypto]

The use-case for this RPC call is in Sammmy007's open-ethereum-pool. The specific location of the RPC getblockbynumber [pending] use is: https://github.com/sammy007/open-ethereum-pool/blob/master/rpc/rpc.go

For reference, this pool software is deployed at the majority of small to medium sized pools, and powers a lot of the smaller ethash coin network mining as well.

[folsen]

@tomusdrw would you like to join the next core dev call to discuss this? I can try to get it added to the agenda