fix: smoldot connection race condition

[kratico]

• Fixes subscription handler setup (Connection.handle was invoked before the subscription handler was set)
• Add unit test for Smoldot

[harrysolovay]

LGTM

[tjjfvi]

Why were these changes to subscription reverted?

[harrysolovay]

@kratico found a bug in which the subscription handler is not set before the first message is received. Was specific to Smoldot if I'm not mistaken.

[kratico]

@harrysolovay @tjjfvi this is surfaced with smoldot because it Connection.handle is invoked before the subscription handler is set.
It may happen with WebSockets too but, most of the time, the first subscription message in WS is not very fast as in smoldot.

[tjjfvi]

Ah, does smoldot send multiple messages synchronously? In that case, it wouldn't be a question of speed, just the microtask from the await.

[kratico]

I believe that for this particular subscription, the chainHead_unstable_follow responds with 2 messages very quickly

• the response for the subscription id
• the response for the first subscription message

It's a microtask race condition

For the above subscription, this smoldot loop run 2 times

    while (true) {
      try {
        const response = await Promise.race([
          this.listening,
          chain.nextJsonRpcResponse(),
        ])
        if (!response) break
        this.handle(JSON.parse(response))
      } catch (_e) {}
    }

before this connection.subscription

    const message = await this.#call(id, subscribe, params)
    if (signal.aborted) {
      delete this.subscriptionPendingInits[id]
      return
    }
    if (message.error) {
      delete this.subscriptionPendingInits[id]
      return handler(message)
    }

[tjjfvi]

Ah yes, I believe this is because deferred.resolve uses two microtask ticks (first to resolve the argument, then to resolve the real promise). I plan to report this to deno std (this, along with another related issue with deferred), but this is a good solution for now.