client: Is there a way to know when GrandpaWarmSync finished?

[lexnv]

I have a simple light_client_parachains.rs example where 2 chains are added to smoldot, then the subxt submits several requests to smoldot to subscribe to new blocks.

While the Grandpa warp sync is in progress, the RPC requests are stored in a pending queue, and their responses will be provided after the warp sync completes.

Is there a way of knowing from the light-client object perspective when the warp sync is completed? (ie initialization completed)
It may be beneficial to distinguish to end-users between the time spent in initialization and the time it took a request to finish.

From this example, it took roughly 10 seconds to sync and provide a response. However, from paritytech/subxt-explorer#8 perspective where sometimes syncing takes 30+ seconds it might be beneficial to display an initialization state to the end user.

Added chain...

2023-11-06T12:33:37.547093Z DEBUG json-rpc-polkadot: PendingRequestsQueue <= {"jsonrpc":"2.0","id":"1", "method":"chain_getFinalizedHead","params":[]}

2023-11-06T12:33:48.996557Z  INFO sync-service-polkadot: GrandPa warp sync finished to #18049008 (0xaba0…21d2)
2023-11-06T12:33:48.997577Z  INFO runtime-polkadot: Finalized block runtime ready. Spec version: 9431. Size of `:code`: 1.4 MiB.

2023-11-06T12:33:48.998083Z DEBUG json-rpc-polkadot: JSON-RPC <= {"jsonrpc":"2.0","id":"1","result":"0xaba091c17377387503ba374852d9420ed18a931c7299c8454b487b4d18c021

[tomaka]

First of all, all non-"system"/"meta" interactions with the client should be done with JSON-RPC functions.
I'm not going to add JavaScript or Rust functions for that kind of things. JSON-RPC functions is how you know everything about a specific chain. Therefore this issue belongs to the JSON-RPC spec repo.

---

When it comes to knowing when the Grandpa warp sync is complete, that's just not possible.
At the moment, yes smoldot indeed does an initialy warp sync then stays at the head of the chain.
However, as explained in #1109, this is not a robust way to do things.

It is possible for example for smoldot to connect to a full node that is stuck one block ahead it, sync the chain using this full node, then realize that the rest of the chain is 5000 blocks ahead. When that happens, we need to resume warp syncing. Then maybe later we connect to another node which says that it is 10000 blocks ahead, and we start warp syncing, but realize that the node was malicious and lying, so the warp syncing gets cancelled.

Another example is if the chain is very close to where the light client is (which is not an uncommon scenario: if someone refresh the tab where smoldot is running, and a database was saved, it will reload and restart syncing exactly where it was), then a warp sync is unnecessarily expensive and it is possible to simply download the few missing blocks.

Basically, it's not possible to simplify this to "the warp syncing is finished".

---

While the Grandpa warp sync is in progress, the RPC requests are stored in a pending queue, and their responses will be provided after the warp sync completes.

That's not accurate for the new JSON-RPC API. It is the case for some of the old ones, but that's due to design issues with the old ones.
In the case of chain_getFinalizedHead, smoldot waits until the end of the warp syncing because PolkadotJS doesn't understand that the storage of the block might be unavailable. As such, we try to only report recent blocks through it (note the try because it's not a robust way to do things, see above).

As explained in the JSON-RPC API spec, if you call chainHead_follow(false), it will immediately return and give you the block at which smoldot currently is.

[tomaka]

Closing since this is a JSON-RPC specification issue anyway.