Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#8,031 3 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@ninglinLiu ya está trabajando en esto.

Desde el 22/10/2026.

  • #8063 de @ninglinLiu — abierto

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python
Área
audio-video-rtc, backend

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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
Lenguaje dominante
Python
Estrellas
14.6k
Forks
3.9k
Merge medio
3 d 21 h
PR fusionados (30 d)
197

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de livekit/agents

Todos los issues de livekit/agents

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.