Lightclient gossiping not available - OpenFailed ProtocolNotAvailable #1330
Comments
I don't know but can you provide some steps how to reproduce that? Could be something in the chain spec that causes that because the chain spec is passed/handled by smoldot and subxt isn't managing that directly.... when @lexnv is back he can probably take a look as well
It's implemented by the subxt but it's not used when initializing the client because LightClientBuilder::build calls from_rpc_client which using the legacy RPC We should fix that and I think the reason is that the new RPC spec was implemented after the LightClient was initially added but thanks for raising the issue. @lexnv any other reasons for that? |
|
I generate the chainspec using the following commands from a substrate node template: ./target/debug/node-template build-spec > chain_spec.json
./target/debug/node-template build-spec --chain=chain_spec.json --raw --disable-default-bootnode > customSpecRaw.jsonThe rest is described above. Nothing special added to the bootstrapping process. |
Just to add; Subxt has two "backends" which determine the RPC methods that will be called. The "legacy backend" is the default one, and calls the "legacy" (ie old) RPC methods. Smoldot emits the warnings you see when such legacy methods are used, because they are not properly specified. Subxt also supports the "new" chainHead RPC methods which will eventually replace these and are properly specified (see https://paritytech.github.io/json-rpc-interface-spec). These are not the default yet though becaus they are still a WIP and aren't themselves stabilised yet, so they may break at any time. When they are stabilised, Subxt will use them by default and the warnings will go away.
It appears from the logs that the We should also double check that we can configure a light client to point to a dev node and it works ok still (eg start with this example https://github.com/paritytech/subxt/blob/master/subxt/examples/light_client_tx_basic.rs and if that works as-is, we could try to export the chainspec as above and does that still work?) |
After cloning
I also tried removing the |
|
From looking at the logs, the issue seems to be that the lightclient is stuck during warp sync: 2024-01-03T20:45:19.583161Z WARN sync-service-local_testnet: GrandPa warp sync idle at block #0 (0x0x957e…5c38)
...
2024-01-03T20:45:39.585799Z WARN sync-service-local_testnet: GrandPa warp sync idle at block #0 (0x0x957e…5c38)This is most likely related to my investigation work #1355 and #1354 and the following smoldot issue smol-dot/smoldot#1562. To work around the issue, I would try cherry-picking this patch: d4da628; although a proper fix in smoldot should handle this for production use-case |
|
After applying this patch d4da628, I get this error still when it attempts to download blocks:
Code snippet for bootstrapping lightclient: // ...
info!("Lightclient bootstrapping API...");
let api = LightClient::<PolkadotConfig>::builder()
.bootnodes(chain.bootnodes())
.max_pending_requests(NonZeroU32::MAX)
.build(chain_spec)
.await
.expect("Failed to create light client");
info!("API bootstrapped!");
// ... |
|
Hey, thanks for letting us know. Could you retry running with the latest origin/master? |
|
Hello! I've tried to use the new version and this problem persists. I am generating the chain spec as @snowmead mentioned. The code is the example with just the chain spec changed. |
Discussed in #1325
Originally posted by snowmead December 19, 2023
Based on this subxt
LightClientexample, the gossip protocol does not seem to be available.My configuration is based on the raw chain spec built from the template node I am running and overriding the bootnodes to connect to the locally running node.
The
awaiton thebuild()function hangs and loops with the same logs shown below.Lightclient logs:
And I have this warning message regarding the RPC api used to query
chain_getFinalizedHead.The legacy RPC call is being utilized instead of the new one. Is there some flag or configuration I need to specify to fix this, or is it simply not implemented in the library yet?
The text was updated successfully, but these errors were encountered: