Runtime upgrade with dev console + smoldot spins indefinitely with console errors

[seadanda]

I tried using the dev console with the light client to system.apply_authorized_upgrade.

This involves uploading the wasm and submitting unsigned (to avoid hefty fees), but when I submitted it I get a transaction when moves to state transaction signed as shown below

then hangs there indefinitely. In the console logs I can see that a websocket connection fails:

WebSocket connection to 'wss://boot-polkadot.luckyfriday.io/' failed:
connect$1 | @ | index-p-BkVK_1.js:28

It iterates through the bootnodes with this same error, then I just get

Disconnected from polkadot{.js}-0x6e10e163a1550e8d-content
3page.js:1 Attempt 1 failed: Could not establish connection. Receiving end does not exist.

repeated at some timeout.
I'm not sure if those issues are relevant, but I see nothing else that looks like it could be the issue. I left it running for about 20 minutes and it got nowhere.

Reproduce for Polkadot relay's recent upgrade:

npx @acala-network/chopsticks@latest -c polkadot --block 0x4c34d458d2dcd911f89eacf06abca096dacd4c94cb24ce00b694c8d6c4a0ec56

Connect to this local via smoldot and system->apply_authorized_upgrade and upload the relay WASM from the fellows v1.4.0 release then submit the extrinsic unsigned.

Note that I haven't actually reproduced it locally. You'll need to insert your magic here to connect using smoldot (is there a guide to doing this with local chains?), when I connect to my chopsticks instance via ws://127.0.0.1:8000 it works fine.

[voliva]

Thanks for the report!

The logs you're seeing connecting to nodes is smoldot trying to connect to some that might be unavailable, but it's normal. It should still work if it's connected to others.

It's really tricky to run smoldot to target a local node... It needs a chainSpec as an input, with a boot node on local, which must be a full node with a full sync (to generate proofs). I'm not sure chopsticks can be used here, maybe we can try with zombienet. I'll give it a shot.

It would be interesting to see what are the messages through the JSON-RPC, but those logs are only enabled when running the console in dev (i.e. locally, with pnpm dev). If you can run the console locally that would be great. We might add a flag somewhere to activate them on the deployed version.

[voliva]

I've managed to reproduce it, the call to validate the transaction before broadcasting it fails with a "operation inaccessible", probably because it's too large.

This might be an issue with polkadot-api, we're investigating solutions.

[seadanda]

Thanks for the info, yea I wondered if the size was a factor - compressed runtimes can theoretically be up to 3MiB (currently more like 1-2 for system chains).

Kusama ones are about the same