Channel Consumption Bug in Retry Logic (STT/TTS)

[darshankparmar]

Bug Description

Retry mechanisms in base classes cause data loss in STT and TTS plugins.

When a plugin's _run() method fails and is retried, the _input_ch channel has already been consumed by the first attempt.

Expected Behavior

Retry logic should reprocess the complete input data on subsequent attempts, not partial/empty data.

Reproduction Steps

1. 
2.
3.
...
- Sample code snippet, or a GitHub Gist link -

Operating System

Linux (tested), likely affects all platforms

Models Used

No response

Package Versions

livekit-agents=1.3.12

Session/Room/Call IDs

No response

Proposed Solution

Additional Context

No response

Screenshots and Recordings

No response

[darshankparmar]

After digging deeper into the codebase, I think this retry bug is fundamentally hard to fix for streaming STT.

STT consumes audio frames from _input_ch in real time and forwards them immediately to the provider. Once a retry happens, the channel has already been partially or fully consumed, and there is no way to replay those frames. Unlike TTS (replayable text input), audio streams are ephemeral. Buffering all frames for retry would break real-time constraints and risk unbounded memory usage, and there’s no clear utterance boundary to know what should be replayed.