a transient Deepgram disconnect can crash the entire AgentSession, not just reconnect the STT leg.
When Deepgram closes the socket, recv_task handles it properly (raises a typed, retryable APIStatusError). But send_task in SpeechStream._run() can be mid-write at the same moment and throws a raw aiohttp.ClientConnectionResetError instead — it’s not wrapped in try/except like recv_task is. Since core stt.py only retries on the APIError hierarchy and treats everything else as unrecoverable, that raw exception kills the whole session if it happens to land first.
Checked and it’s still there on main (not just our pinned 1.6.1) — same unwrapped ws.send_bytes() in both stt.py and the newer stt_v2.py.
I took a look at this with Claude and confirmed the issue.
```
In SpeechStream._run() (both stt.py and stt_v2.py, current main), recv_task and send_task handle a socket drop asymmetrically:
recv_task converts an unexpected close into a typed APIStatusError(retryable=True).send_task’s await ws.send_bytes(...) / send_str(...) are unwrapped, so a mid-write drop raises raw aiohttp.ClientConnectionResetError (not in the APIError hierarchy).
Both tasks live in one asyncio.gather, and _run re-raises whichever fails first. So one physical disconnect is a race:
- recv wins →
APIError caught by RecognizeStream._main_task, retried/reconnected. Fine.
- send wins → raw exception isn’t matched by
_main_task’s except APIError, so it escapes with no retry and no _emit_error — the stream task just dies, taking the session down instead of reconnecting.
Fix: wrap the writes in send_task and re-raise connection errors as APIConnectionError/APIStatusError(retryable=True) so send is symmetric with recv (and swallow-and-return on expected close, like recv_task does). Scope the catch to connection errors, not bare Exception.
Same unwrapped-send_bytes pattern exists in other plugins (elevenlabs, inference STT). Related but distinct from #4609. ElevenLabs STT stream does not reconnect after mid-stream WebSocket disconnection · Issue #4609 · livekit/agents · GitHub
```
Thanks @Edward_Ed_Charbeneau - Ed is on the Deepgram DevRel team 
@Edward_Ed_Charbeneau what is the best next step here, will you raise this on our internal channel, or shall I?
I’ll bring this up in our internal Slack. Where our teams can discuss.