Smoldot has panicked while executing task sync-service-rococo_v2_2

[kratico]

Getting this error

Smoldot has panicked while executing task `sync-service-rococo_v2_2`. This is a bug in smoldot. Please open an issue at https://github.com/smol-dot/smoldot/issues with the following message:
panicked at 'assertion failed: curr.start_slot_number <= parent_slot_number', lib/src/verify/babe.rs:279:9

With the following script shared in stackblitz

import { start } from "smoldot"
import chainSpec from "./rococo_v2_2.json" assert { type: "json" }

const client = start()

const chain = await client.addChain({ chainSpec: JSON.stringify(chainSpec) })

chain.sendJsonRpc(
  JSON.stringify({
    jsonrpc: "2.0",
    id: "id",
    method: "chainHead_unstable_follow",
    params: [true],
  }),
)

while (true) {
  try {
    console.log(await chain.nextJsonRpcResponse())
  } catch (error) {
    console.error(error)
    break
  }
}

chain.remove()

client.terminate()

I've checked this in stackblitz with Node v18.18.0 and the following smoldot versions

• v2.0.7, panicked at 'assertion failed: curr.start_slot_number <= parent_slot_number', lib/src/verify/babe.rs:280:9
• v2.0.6 and v2.0.3, stuck with [sync-service-rococo_v2_2] GrandPa warp sync idle at block #7527149 (0x0x6cc8…d74a)

Then, testing locally with OSX and Node v18.18.0, smoldot versions v2.0.7, v2.0.6 and v2.0.3 panic.

Note:

• I didn't have this issue on Monday with [email protected] so it might be related to a change in Rococo
• Other chains (Polkadot, Kusama, Westend) are working fine

[pepoviola]

Hi @kratico, I think is related to a current issue in rococo (the chain is currently stalled because of a wrong upgrade).

[kratico]

Thx @pepoviola

Follow up question, Should the smoldot client crash if a single chain is stalled?

[kratico]

FYI, I'm using smoldot with many chains.
It is unfortunate that a single chain could make the smoldot client crash.

What would be the right way to recover from that?

[tomaka]

Smoldot isn't supposed to crash in that situation (or any situation). The message that you've copy-pasted mentions "this is a bug in smoldot".
#519 would help here, but until WebAssembly exception handling becomes stable it's kind of pointless.

[tomaka]

It seems that the runtime says that a certain Babe epoch starts at slot N, whereas the header of a block within that epoch says that its slot number is M, where M < N.

The Babe verification code panics if the configuration of the chain is invalid (like is the case right now), but the code built on top of it doesn't check this specific configuration point.

[tomaka]

In addition to fixing the issue (by checking this configuration point), I'm going to remove the panics in Aura and Babe, as the panic reason is too hard to reason about, and instead return some kind of InvalidConfiguration error.
In the higher level code I'll add a debug_assert! in case of InvalidConfiguration error, so that smoldot only crashes in debug mode.