feat(deepgram): surface Deepgram TTS request_id via lk.provider_request_ids#6293
Open
OpTensorAbdullah wants to merge 1 commit into
Open
Conversation
…st_ids The Deepgram TTS plugin discarded the provider Metadata frame and used a local shortuuid for the request id, so lk.provider_request_ids (added in livekit#5546) never carried Deepgram's real request id for TTS spans — unlike the Deepgram STT plugin. Read request_id from the Metadata frame and pass it to output_emitter._note_provider_request_id(), matching the STT/Sarvam/UpliftAI plugins. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
PR #5546 added
lk.provider_request_idsto TTS/STT/LLM spans, but the Deepgram TTS plugin was not included (it covered the base plus OpenAI/Sarvam/UpliftAI). Deepgram STT already surfacesmetadata["request_id"], but Deepgram TTS discards the providerMetadataframe (elif mtype == "Metadata": pass) and the span's request id is a localutils.shortuuid(). As a result there is no way to correlate a Deepgram TTS request/failure with Deepgram's server-side logs.What this does
Reads
request_idfrom Deepgram's TTSMetadataframe and passes it tooutput_emitter._note_provider_request_id(...), so it appears on thetts_request_runspan underlk.provider_request_ids— matching the Deepgram STT plugin and the Sarvam/UpliftAI TTS plugins.Deepgram's TTS WebSocket Metadata message carries the id at the top level:
{ "type": "Metadata", "request_id": "...", "model_name": "aura-2-...", ... }(ref: https://developers.deepgram.com/docs/tts-websocket)
Why
Real-time users hitting Deepgram TTS WebSocket issues currently can't hand Deepgram support a request id, because the id surfaced by the plugin is a local one rather than Deepgram's. This closes that gap for Deepgram TTS specifically.
Tested
Applied the change locally and ran a synthesis through the plugin. It captured a
request_idfrom the Metadata frame that resolves in the Deepgram console to the exact/speakrequest (matching endpoint,encoding=linear16,sample_rate=24000, and timestamp) — confirming the captured value is Deepgram's real, searchable request id rather than a local one.Note:
_note_provider_request_iddedupes internally, so calling it on every Metadata frame is safe.