Light Client: subxt API will do nothing after smoldot thread panic.

[david9991]

Here is the example:

let mut sub = edge
                .api()
                .await
                .blocks()
                .subscribe_finalized()
                .await
                .unwrap();
while let Ok(block) = sub.next().await.unwrap() {
}

After several blocks had been subscribed, smoldot thread reported an error:

thread 'smoldot-light-2' panicked at /home/gitlab-workspaces/.cargo/registry/src/index.crates.io-6f17d22bba15001f/smoldot-light-0.14.0/src/runtime_service.rs:472:34: called `Result::unwrap()` on an `Err` value: ()

But let Ok(block) = sub.next().await.unwrap() will keep blocking there without panic, so there is no way to handle this kind of underlying error and causing the program stuck forever.

[lexnv]

Hi,

Could you please provide a bit more details here, on what chain is this happening? 🤔

Since you can reproduce this error, it would greatly help us in raising an issue to smoldot if you could rerun the example with RUST_LOG=debug and tracing enabled 🙏
Smoldot panics when some internal assumption is not held, I believe the purpose of this is for the maintainers to capture errors and fail as soon as possible.

At the moment, we are a bit lagging behind the latest smoldot released version, that is pending a fix from: smol-dot/smoldot#1638

[david9991]

@lexnv Here is the log file (stoped-after-block-86099-full.txt.zip), you can search for Block: 86099 0xe684…2237, it's the last finalized block we had subscribed then the program stuck at Ok(block) = sub.next().await.unwrap(). But the smoldot didn't panic this time.

[jsdw]

If Smoldot panics in this way, I don't think there's much that Subxt can/should do about it, so yup leet's raise this upstream with Smoldot with whatever logs/reproduction we can offer.

We are behind a bit though so if we're lucky it's already been addressed!