[Docs]: Listen V1 websockets examples fail with ConnectionClosedError #632
Description
Affected page or section
https://github.com/deepgram/deepgram-python-sdk/blob/main/websockets-reference.md
What is unclear or wrong?
Unclear if this is a bug or outdated documentation, but running either the sync or async example with a valid API key always results in a ConnectionClosedError, which appears to be caused by connection.start_listening() taking 12 seconds to finish.
Suggested change
Example code (if any)
Here's a slightly modified example which logs output, but the same happens with the original examples:
import logging
from deepgram import DeepgramClient
from deepgram.core.events import EventType
from deepgram.extensions.types.sockets import ListenV1SocketClientResponse
from deepgram.extensions.types.sockets import ListenV1MediaMessage
from deepgram.extensions.types.sockets import ListenV1ControlMessage
logging.basicConfig(
format='%(asctime)s %(levelname)-8s %(message)s',
level=logging.INFO,
datefmt='%Y-%m-%d %H:%M:%S',
)
client = DeepgramClient(
api_key="<REDACTED>"
)
logging.info("created DeepgramClient")
with open("sample.wav", "rb") as fh:
audio_bytes = fh.read(64)
logging.info(f"read {len(audio_bytes)} bytes of audio")
with client.listen.v1.connect(model="nova-3") as connection:
logging.info("created listen.v1 connection")
def on_message(message: ListenV1SocketClientResponse) -> None:
msg_type = getattr(message, "type", "Unknown")
logging.info(f"received {msg_type} event")
connection.on(EventType.OPEN, lambda _: logging.info("Connection opened"))
connection.on(EventType.MESSAGE, on_message)
connection.on(EventType.CLOSE, lambda _: logging.info("Connection closed"))
connection.on(EventType.ERROR, lambda error: logging.info(f"Caught: {error}"))
logging.info("calling start_listening()")
connection.start_listening()
logging.info("sending media")
connection.send_media(ListenV1MediaMessage(audio_bytes))
logging.info("sending KeepAlive")
connection.send_control(ListenV1ControlMessage(type="KeepAlive"))This fails with:
2025-11-11 18:59:10 INFO created DeepgramClient
2025-11-11 18:59:10 INFO read 64 bytes of audio
2025-11-11 18:59:10 INFO created listen.v1 connection
2025-11-11 18:59:10 INFO calling start_listening()
2025-11-11 18:59:10 INFO Connection opened
2025-11-11 18:59:22 INFO received Metadata event
2025-11-11 18:59:22 INFO Caught: received 1011 (internal error) Deepgram did not receive audio data or a text message within the timeout window. See https://dpgr.am/net0001; then sent 1011 (internal error) Deepgram did not receive audio data or a text message within the timeout window. See https://dpgr.am/net0001
2025-11-11 18:59:22 INFO Connection closed
2025-11-11 18:59:22 INFO sending media
Traceback (most recent call last):
File "/private/tmp/dgt/test_sync_deepgram.py", line 42, in <module>
connection.send_media(ListenV1MediaMessage(audio_bytes))
~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/private/tmp/dgt/.venv/lib/python3.13/site-packages/deepgram/listen/v1/socket_client.py", line 214, in send_media
self._send(message)
~~~~~~~~~~^^^^^^^^^
File "/private/tmp/dgt/.venv/lib/python3.13/site-packages/deepgram/listen/v1/socket_client.py", line 195, in _send
self._websocket.send(data)
~~~~~~~~~~~~~~~~~~~~^^^^^^
File "/private/tmp/dgt/.venv/lib/python3.13/site-packages/websockets/sync/connection.py", line 478, in send
with self.send_context():
~~~~~~~~~~~~~~~~~^^
File "/Users/dsc/.local/share/uv/python/cpython-3.13.7-macos-aarch64-none/lib/python3.13/contextlib.py", line 141, in __enter__
return next(self.gen)
File "/private/tmp/dgt/.venv/lib/python3.13/site-packages/websockets/sync/connection.py", line 1012, in send_context
raise self.protocol.close_exc from original_exc
websockets.exceptions.ConnectionClosedError: received 1011 (internal error) Deepgram did not receive audio data or a text message within the timeout window. See https://dpgr.am/net0001; then sent 1011 (internal error) Deepgram did not receive audio data or a text message within the timeout window. See https://dpgr.am/net0001
This happens with the async example too, and even when sending a single byte of audio.
In case it helps, the timeout is always after 12 seconds.
SDK parity (if relevant)
- This change may need updates in other SDKs
Session ID (optional)
No response
Project ID (optional)
No response
Request ID (optional)
No response