A small SDK gap that kept users from tying every streaming event back to its session.
Kort antwoord
Deepgram's Extra Metadata lets you attach key-value pairs to a streaming request and get them back on responses. In the Go SDK, UtteranceEndResponse had no field for them, so users couldn't tell which session an utterance-end event belonged to. The fix adds an Extra field and has both WebSocket routers remember the connection's metadata and attach it to utterance-end events. It was merged as PR #373 and closed issue #302.
The problem
Issue #302, open since June 2025, explained the need: "I use this field to know which session a response is associated with, which I can't do if it's not included in every message type."
The fix
The routers store Extra Metadata whenever a Results or Metadata message carries it, and fill it into UtteranceEnd responses that arrive without it:
r.extraMetadata.store(msg.Metadata.Extra)
...
if len(msg.Extra) == 0 {
msg.Extra = r.extraMetadata.load()
}The same change was made in both the callback router and the channel router. UtteranceEndResponse gained an Extra map[string]string field.
By the numbers
- Repository: deepgram/deepgram-go-sdk, 93 stars (Nov 3, 2026), Go, MIT
- Files changed: 5
- Lines: +226 / -3, including a 165-line test file
- Commits: 2 (1 from the PR author, 1 from a maintainer)
- Opened: Oct 10, 2026. Merged: Oct 13, 2026. Time to merge: 3 days, 3 hours
- Review: approved and merged by a maintainer
How the review went
The maintainer added a commit, "test(listen): cover utterance end extra metadata", with a 165-line test file covering both routers. They then approved and merged the PR.
Veelgestelde vragen
Who added the regression test?
The original PR description claimed a regression test, but the maintainer supplied the 165-line test file in the second commit.
Does this overwrite metadata the server sends on UtteranceEnd?
No. The cached value is only used when the UtteranceEnd message has no Extra Metadata of its own.
Where can I read more?
See the pull request and the original issue.
Het doel
SDK consistency matters most where users build their own routing on top of it. One field and a small cache made every event type carry the same session context.
