fix(sarvam): saaras:v3 does not support the config/prompt message - #6617
Conversation
saaras:v3 connects to wss://api.sarvam.ai/speech-to-text/ws, whose AsyncAPI schema documents only audio-data and flush client messages. The config/prompt message the plugin sent on connect is documented only for the legacy translate endpoint (/speech-to-text-translate/ws), which is used exclusively by saaras:v2.5 - so the prompt was silently dropped server-side and hotword biasing built on it never had any effect. Mark saaras:v3 as supports_prompt=False, stop assuming prompt support for unknown models (they are routed to the non-translate endpoint too), and warn when a caller supplies a prompt that will not be sent, instead of failing silently. Adds hermetic tests pinning prompt support to the translate endpoint. Fixes livekit#6606
|
@biztex Thanks for finding this. Let’s keep the fix scoped to the reported capability mismatch: The existing streaming guard already avoids sending the config frame when prompt support is false, so no further control-flow change is needed. Sarvam silently ignores a raw config/prompt frame on the v3 endpoint, it does not return a provider error, and since saaras:v2.5 is on its way to be deprecated, the LiveKit docs reflect no support for a prompt parameter. Please drop the unknown-model behaviour change, warning logs, and expanded endpoint/protocol commentary. |
scope the fix to the reported capability mismatch, per Sarvam review.
|
Thanks — done in 27c8dc3. It's just the flag now: Kept a two-line test asserting v3 is False and v2.5 is still True, happy to drop that too if you'd rather have it as a pure one-liner. |
Fixes #6606.
MODEL_CONFIGS["saaras:v3"]declaredsupports_prompt=True, so the plugin sent a config/prompt message on a connection that ignores it — callers could setpromptfor hotword biasing and it never reached anything.Sets the flag to
False. The existing streaming guard already skips the config frame when prompt support is false, so no control-flow change is needed.