Unable to use chainHead_v1_call on "Parallel" parachain

[josepot]

When trying to use smoldot against the Parallel parachain, it seems like all the operation requests "fail" with an operationInaccessible event, and after trying a bit later we get the same result over and over.

These are the logs:

• Smoldot low-level logs (I just edited the comment to update these logs, the ones before were not readable)
• Logs of the JSON-RPC messages

The chainSpec for this parachain is:

{
  "name": "Parallel",
  "id": "parallel",
  "chainType": "Live",
  "bootNodes": [
    "/dns/bootnode-1.parallel.fi/tcp/30333/p2p/12D3KooWA3ngBk5UuAvtvANXRJSTjdCT9bz7AcdBqmnR64m3tRWb",
    "/dns/bootnode-5.parallel.fi/tcp/30333/p2p/12D3KooWGxnMnE1AFriohESDGQnpYBzbxBpRDf3MFNu8yuobJBbF"
  ],
  "properties": {
    "ss58Format": 172,
    "tokenDecimals": 12,
    "tokenSymbol": "PARA"
  },
  "relay_chain": "polkadot",
  "para_id": 2012,
  "consensusEngine": null,
  "codeSubstitutes": {},
  "genesis": {
    "stateRootHash": "0xbe7040d6d2832c34c9925e9298e06f1f9818bc5ed62fbf0b57782c8ee7ea8ce1"
  }
}

[tomaka]

What happens is that the full nodes that we ask a Merkle proof from indicate that they're unable to answer the request (basically an error on their side).
There's nothing indicating to smoldot what problem could have happened, so the way forward is to look at what the full node logs say.

[tomaka]

To make smoldot connect to a specific full node, the easiest way is to modify the list of bootnodes to just that one full node.

You also need to modify this line like this:

next_discovery_when: self.platform.now() + Duration::from_secs(10000),

This gives you 10000 seconds between starting smoldot and the moment when it connects to nodes other than just the full node.

You can also not do this source code modification, but then whether the full node is actually queried by smoldot comes down to luck. By doing the modification, you guarantee that 100% of the time smoldot will chose that one full node.
If it's very easy to you to search through the full node logs, it might be easier to not do the modification and just try multiple times, searching through the logs every time.

On the full node side, you have to pass the -l sub-libp2p=debug flag (hopefully this hasn't changed since 2022). I guess that you should be able to search the string "DryRunApi_dry_run_call" in the logs. I really don't remember enough about Substrate to precisely guide you from there, but we're looking for some kind of error message.

[tomaka]

There are some things that can go wrong when connecting smoldot to your full node.
If the full node is on a separate machine, make sure obviously that ports are open. The address a full node is listening on by default is something like /ip4/0.0.0.0/tcp/30334/ws, make sure you have the ws.
The full node should also be fully synced, otherwise smoldot will simply ignore it.
If you're in touch with Parity devops, it might be easier to ask them to help you.

[josepot]

So, I finally managed to get a kusama snapshot and to have a full-node running locally. I have changed the bootnodes of the chainspec so that my local node is the only available bootnode, like this:

"bootNodes": [
    "/ip4/127.0.0.1/tcp/1714/ws/p2p/12D3KooWGtoBv9Xb6VQ9YRWDejxNFxULzpuiR41pKLF9qV45UPnT"
  ],

Now, if I don't do this:

+ Duration::from_secs(10000)

I can reproduce the test, but it seems that it's not my node the peer responding to the smoldot requests, and if I make that change ^, then just nothing happens. I don't even get a response to the initial storage query. I see a message in the logs of the node that reads something like: 2024-11-21 14:52:52.369 DEBUG tokio-runtime-worker sub-libp2p: handshake doesn't contain peer role: []... Could it be that for some reason my node is ignoring the light-client requests? is there a flag that I have to use to prevent that from happening or something?

[josepot]

NVM, I finally managed to reproduce it using my local node by delaying the next discovery as @tomaka suggested. Every time that I try to run the script I can see the following logs on my node:

2024-11-21 15:34:26.158 ERROR tokio-runtime-worker runtime: panicked at /home/builder/cargo/registry/src/index.crates.io-6f17d22bba15001f/polkadot-runtime-common-15.0.0/src/xcm_sender.rs:149:98:
called `Result::unwrap()` on an `Err` value: Error

[tomaka]

I guess that you should report that to the Polkadot repo.