Smoldot WebSocket connection attempts after chain.remove()

[kratico]

Using smoldot in the browser, after invoking chain.remove() additional connection attempts are made to the removed chain.

Added a stackblitz to reproduce the issue.
Note: to see console.log messages, click on Open in New Tab and then open the console in the new tab.

The following screenshot is reproduced with this script that removes the chain after 15s and terminates the client after 60s.
In between, there are WebSocket connection attempts

import chainSpec from './westend2.json';
import * as smoldot from 'smoldot';

window.WebSocket = class extends WebSocket {
  constructor(...args) {
    console.log('will connect', ...args);
    super(...args);
  }
};

const client = smoldot.start();
console.log('will add chain');
const chain = await client.addChain({ chainSpec: JSON.stringify(chainSpec) });

await new Promise((resolve) => setTimeout(resolve, 15_000));

console.log('will remove chain');
chain.remove();

// check websocket connections between these setTimeouts

await new Promise((resolve) => setTimeout(resolve, 60_000));

console.log('will terminate client');
client.terminate();

[tomaka]

This is kind of expected, assuming the connection attempts are not long after removing the chain.

"Removing a chain" internally just sends around messages telling subsystems to shut down, and then returns. It's not waiting for the shut downs to actually happen. All the subsystems will finish what they are currently doing before shutting down.

The log message saying that the memory usage is only 160 kiB is a strong hint that everything has likely been shut down properly at that point.

[tomaka]

I agree that it's a bit weird that the connection attempts would happen coincidentally right after removing the chain.

However I can't give a better opinion without more verbose logs.

[josepot]

However I can't give a better opinion without more verbose logs.

There was a stackblitz setup for your convenience. I used it to generate more verbose logs, here you go:
localhost-1693690935269.log

[tomaka]

However I can't give a better opinion without more verbose logs.

There was a stackblitz setup for your convenience. I used it to generate more verbose logs, here you go: localhost-1693690935269.log

The problem doesn't happen in your logs.

[kratico]

Attaching more verbose logs and updated the stackblitz example to prefix app logs with [app] and smoldot.start({ maxLogLevel: 99 })

vitejsvitemkrc2k-cpxq--5173--33975f1d.local-credentialless.log

At line 373 there is an entry for [app] chain.remove() (when the chain is removed) and starting from line 614 there are entries prefixed with [app] WebSocket connect ... (extra WS connection attempts)

With more verbose logs, these Worker =>/<= entries were noticed

[tomaka]

Ah thanks, so subsystems indeed aren't getting shut down for some reason.
I'll add more logging in a PR (so a future version), but right now I'm not sure why.

Could you try passing disableJsonRpc: true in the options when calling addChain?

If it still happens then I'd suspect the runtime service, and if it doesn't happen anymore then it's the JSON-RPC service.

[kratico]

Added disableJsonRpc: true to addChain and it seems to be the same.

Attached are the logs

vitejsvitemkrc2k-cpxq--5173--33975f1d.local-credentialless.log

[tomaka]

Found the culprit.

The transactions service waits for the warp sync to be finished before starting to process messages from the foreground.