Soniox and simplismart STT detect a dead websocket and reconnect into it forever instead of failing over

Read the Soniox and simplismart STT receive loops in livekit-plugins-soniox/.../stt.py and livekit-plugins-simplismart/.../stt.py, then run the issue's half-open probe with soniox simplismart. Decide how detected silent reconnects should reach stt.FallbackAdapter; the issue lists three possible policies and leaves that choice open. Done when the selected behavior prevents silent infinite reconnects and is covered against the reproduced case.

Summary

The soniox and simplismart STT streams detect a half-open websocket correctly and then tell nobody. Both reconnect into the same dead state and repeat indefinitely, so stt.FallbackAdapter is never informed and the caller stays unheard for the rest of the call.

This is the third category that came out of extending @DEVJHAWAR11's probe in #7900 to all nineteen streaming STT plugins. #7900 covers the plugins that never notice at all. These two do notice — which is arguably worse, because the stream looks healthy the whole time.

Measured

A local server accepts the websocket upgrade and then sends nothing and answers no pings — a provider, or a NAT in between, that vanished without a FIN or an RST. Captured today against 3c6e65124:

    217ms  livekit.plugins.soniox  Soniox Speech-to-Text API connection established!
  46898ms  livekit.plugins.soniox  Soniox STT WebSocket error frame: ServerTimeoutError('No PONG received after 15.0 seconds')
  46899ms  livekit.plugins.soniox  Soniox STT WebSocket closed; requesting reconnect
  46906ms  livekit.plugins.soniox  Soniox Speech-to-Text API connection established!

Reconnected 8 ms after detecting the dead socket, into a server that is still silent, and round again every ~46.7 s for as long as the stream lives. Nothing is raised, so the watch expires with the stream still "running". simplismart does the same at ~50.6 s, logging simplismart connection lost.

The ~46.7 s is heartbeat=30.0 plus aiohttp's 15 s pong wait plus connect. Both plugins pass a heartbeat, which is why they detect it; three other plugins pass one and fail over correctly (smallestai 46.4 s, telnyx 46.9 s, deepgram 47.0 s), so detection is clearly not the missing piece.

Mechanism

soniox (livekit-plugins-soniox/.../stt.py)

The heartbeat's unanswered ping surfaces as WSMsgType.ERROR, which is logged and then breaks out of the receive loop without raising:

if msg.type == aiohttp.WSMsgType.ERROR:                      # L542
    logger.warning("Soniox STT WebSocket error frame: %r", self._ws.exception())
    break                                                    # L548

_recv_messages_task then returns normally and arms a reconnect on its way out (note this bypasses _request_reconnect, so it is not subject to that method's guards):

# Request reconnect if STT silently dies on WS drop.
if not self._reconnect_event.is_set():                       # L686
    logger.warning("Soniox STT WebSocket closed; requesting reconnect")
    self._reconnect_event.set()

_run's while True at L345 sees wait_reconnect_task complete, clears the event, and calls _connect_ws() again. No exception ever leaves _run, so the base stt.SpeechStream never learns the stream failed.

simplismart (livekit-plugins-simplismart/.../stt.py) is the same shape in one place rather than two:

if msg.type == aiohttp.WSMsgType.ERROR:                      # L388
    if self._session.closed:
        return
    logger.warning("simplismart connection lost: %r", ws.exception())
    self._reconnect_event.set()
    return

conn_options does not bound it

I expected max_retry=0 to cap this, and it does not. The retry budget belongs to the base class, and this reconnect is the plugin's own loop, so it is invisible to it. The probe runs with APIConnectOptions(max_retry=0, timeout=10) and soniox still reconnects indefinitely.

Why I am filing this rather than sending a patch

The correct behaviour is a judgement call I do not think belongs to a contributor:

1. Bound the plugin's own reconnects — after N consecutive reconnects with no traffic received, raise so the base class and FallbackAdapter can act.
2. Treat a reconnect that produces no traffic as a failure — reconnecting is right once; reconnecting forever into silence is not.
3. Leave it, and document that these two plugins do not fail over so nobody puts them behind a FallbackAdapter expecting they will.

Option 1 needs a number, and the ~46.7 s above is already nobody's considered choice — every plugin that passes a heartbeat passes 30.0. I would rather you pick than guess in a PR. Happy to implement whichever you want.

One scoping note in fairness to both plugins: this models a server that accepts connections and then goes silent — a load balancer in front of a dead backend, or a provider bug. Against a provider that has genuinely vanished the reconnect would fail and surface an error normally.

Reproducing

Probe, per-plugin construction table and raw results: https://github.com/Rehansanjay/livekit-stt-halfopen

# from a livekit/agents checkout with the workspace installed
uv run python probe/halfopen_probe.py soniox simplismart