Skip to content

feat(deepgram): surface Deepgram TTS request_id via lk.provider_request_ids#6293

Open
OpTensorAbdullah wants to merge 1 commit into
livekit:mainfrom
OpTensorAbdullah:feat/deepgram-tts-provider-request-id
Open

feat(deepgram): surface Deepgram TTS request_id via lk.provider_request_ids#6293
OpTensorAbdullah wants to merge 1 commit into
livekit:mainfrom
OpTensorAbdullah:feat/deepgram-tts-provider-request-id

Conversation

@OpTensorAbdullah

Copy link
Copy Markdown

Summary

PR #5546 added lk.provider_request_ids to TTS/STT/LLM spans, but the Deepgram TTS plugin was not included (it covered the base plus OpenAI/Sarvam/UpliftAI). Deepgram STT already surfaces metadata["request_id"], but Deepgram TTS discards the provider Metadata frame (elif mtype == "Metadata": pass) and the span's request id is a local utils.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_id from Deepgram's TTS Metadata frame and passes it to output_emitter._note_provider_request_id(...), so it appears on the tts_request_run span under lk.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_id from the Metadata frame that resolves in the Deepgram console to the exact /speak request (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_id dedupes internally, so calling it on every Metadata frame is safe.

…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>
@OpTensorAbdullah OpTensorAbdullah requested a review from a team as a code owner July 2, 2026 11:48
@CLAassistant

CLAassistant commented Jul 2, 2026

Copy link
Copy Markdown

CLA assistant check
All committers have signed the CLA.

@devin-ai-integration devin-ai-integration Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no bugs or issues to report.

Open in Devin Review

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants