[chainHead_follow] newBlock event with an unreported parentBlockHash

[sinzii]

Problem

Smoldot v2.0.24

I happened to call some legacy JSON-RPC before calling chainHead_v1_follow, this frequently results in the first newBlock event after initialized event having an unknown/unreported parentBlockHash which I suppose it should be reported earlier in the finalizedBlockHash/finalizedBlockHashes prop of initialized event.

This is one of the logs I get:

[smoldot] Smoldot v2.0.24
[smoldot] Chain initialization complete for polkadot. Name: "Polkadot". Genesis hash: 0x91b1…90c3. Chain specification starting at: 0x9548…ebd3 (#20408370)
[runtime-polkadot] Finalized block runtime ready. Spec version: 1002000. Size of `:code`: 1.5 MiB.
>>: {"id":1,"jsonrpc":"2.0","method":"chain_getBlockHash","params":[0]}
[json-rpc-polkadot] The JSON-RPC client has just called a JSON-RPC function from the legacy JSON-RPC API (chain_getBlockHash). Legacy JSON-RPC functions have loose semantics and cannot be properly implemented on a light client. You are encouraged to use the new JSON-RPC API <https://github.com/paritytech/json-rpc-interface-spec/> instead. The legacy JSON-RPC API functions will be deprecated and removed in the distant future.
<<: {"jsonrpc":"2.0","id":1,"result":"0x91b171bb158e2d3848fa23a9f1c25182fb8e20313b2c1eb49219da7a70ce90c3"}
>>: {"id":2,"jsonrpc":"2.0","method":"state_getRuntimeVersion","params":[null]}
>>: {"id":7,"jsonrpc":"2.0","method":"chainHead_v1_follow","params":[true]}
<<: {"jsonrpc":"2.0","id":7,"result":"5jvnxeeLFS3DNtQWBM8Nz5dvx7aWnLYd3GLz9vpzXwRY"}
<<: {"jsonrpc":"2.0","method":"chainHead_v1_followEvent","params":{"subscription":"5jvnxeeLFS3DNtQWBM8Nz5dvx7aWnLYd3GLz9vpzXwRY","result":{"event":"initialized","finalizedBlockHash":"0x87bcfce14cd661f72f9a6e5a6c76b2df60403c0ff4f1a413febe248dc9938174","finalizedBlockRuntime":{"type":"valid","spec":{"specName":"polkadot","implName":"parity-polkadot","specVersion":1002000,"implVersion":0,"transactionVersion":25,"apis":{"0xf78b278be53f454c":2,"0xed99c5acb25eedf5":3,"0xdf6acb689907609b":4,"0x40fe3ad401f8959a":6,"0xd2bc9897eed08f15":3,"0x18ef58a3b67ba770":1,"0x49eaaf1b548a0cb0":3,"0x91d5df18b0d2cf58":2,"0x2a5e924655399e60":1,"0x37c8bb1350a9a2a8":4,"0x37e397fc7c91f5e4":2,"0x17a6bc0d0062aeb3":1,"0xf3ff14d5ab527059":3,"0xbc9d89904f5b923f":1,"0xfbc577b9d747efd6":1,"0xcbca25e39f142387":2,"0xaf2c0297a23e6d3d":10,"0xab3c0572291feb8b":1,"0x687ad44ad37f03c2":1}}}}}}
<<: {"jsonrpc":"2.0","method":"chainHead_v1_followEvent","params":{"subscription":"5jvnxeeLFS3DNtQWBM8Nz5dvx7aWnLYd3GLz9vpzXwRY","result":{"event":"newBlock","blockHash":"0x72d75fe7a1b03da1eb18087ed2d054327ace8d48a9ba4f3e9fcb69cb250a0689","parentBlockHash":"0xa641fa20c2918e2f726cb79ee3be56d47e034bb7c627cd846a10dfb24ff10cbe","newRuntime":null}}}
<<: {"jsonrpc":"2.0","method":"chainHead_v1_followEvent","params":{"subscription":"5jvnxeeLFS3DNtQWBM8Nz5dvx7aWnLYd3GLz9vpzXwRY","result":{"event":"newBlock","blockHash":"0x19562e9ab38f43a9fe24d1e5010613e09e8e6ed601adb8f3d6d6b44ed4c71867","parentBlockHash":"0x220338187848ed56f420a6ac1b2da0275365e7be13200f24f4cb9e8ea4c34ddd","newRuntime":null}}}
<<: {"jsonrpc":"2.0","method":"chainHead_v1_followEvent","params":{"subscription":"5jvnxeeLFS3DNtQWBM8Nz5dvx7aWnLYd3GLz9vpzXwRY","result":{"event":"newBlock","blockHash":"0xb45cb4be78e29eebecd1cc2fe0d50e1c75e14e249dc2587490b14c013c2efba9","parentBlockHash":"0xa47651ff8851e1fa411c9ff8852c10c0f51e716fb4de83dfe58be92998de7266","newRuntime":null}}}
<<: {"jsonrpc":"2.0","method":"chainHead_v1_followEvent","params":{"subscription":"5jvnxeeLFS3DNtQWBM8Nz5dvx7aWnLYd3GLz9vpzXwRY","result":{"event":"bestBlockChanged","bestBlockHash":"0xb45cb4be78e29eebecd1cc2fe0d50e1c75e14e249dc2587490b14c013c2efba9"}}}
<<: {"jsonrpc":"2.0","method":"chainHead_v1_followEvent","params":{"subscription":"5jvnxeeLFS3DNtQWBM8Nz5dvx7aWnLYd3GLz9vpzXwRY","result":{"event":"finalized","finalizedBlockHashes":["0x72d75fe7a1b03da1eb18087ed2d054327ace8d48a9ba4f3e9fcb69cb250a0689"],"prunedBlockHashes":[]}}}

As noted in the spec,

parentBlockHash is guaranteed to be equal either to the current finalized block hash, 
or to a block reported in an earlier newBlock event.

I suppose the current finalized block hash should be reported in the initialized event, so I think this should be a problem.

How to reproduce

Please run this script with this polkadot-spec

I've played the script a lot of times and got the same result most of the cases, so if you don't see it right from the first run, please run it again a few more times.

Weirdly, if I run the script without the first 2 requests, I don't get this issue anymore.

[josepot]

Dup of #1788

[sinzii]

@josepot Oh, it seems like the same issue, but this time it was triggered by a differrent way via the legacy APIs. I'm not sure if there's other places that could lead to this. @tomaka Could you confirm that this is also fixed by #1791. I'd appreciate it!

[sinzii]

Interesting, I've reduced the delay between each request in the script, and the issue is gone. So I think it mostly because of #1788. I'm closing this for now. Thanks @josepot!