Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#8,031 3 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@ninglinLiu is already working on this.

Since Oct 22, 2026.

  • #8063 by @ninglinLiu — open

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
audio-video-rtc, backend

Research direction

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.

Written by the indexing model from the issue text.

Description

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
Dominant language
Python
Stars
14.6k
Forks
3.9k
Avg merge
3d 21h
Merged PRs (30d)
197

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from livekit/agents

All issues in livekit/agents

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.