Repository navigation
feat(regen): add Listen V1 ConfigureSuccess and ConfigureFailure replies - #803
Conversation
|
GregHolmes
changed the title
dg-coreylweathers
left a comment
dg-coreylweathers
left a comment
There was a problem hiding this comment.
Requesting changes. One item, and the fix belongs upstream in deepgram-docs.
What this PR does: regenerates the Python SDK from deepgram-docs 59a99c27 and re-applies every manual patch. The one developer-visible change is the keyterms docstring on Listen V1 Configure. It now says an over-limit update stops transcription and closes the stream with 1011 (NET-0000) after about 30 s.
[B1] Production doesn't behave that way today. Two live prod streams with 250 keyterms (~11k chars) sent in a Configure got no Error and no other message. Transcription continued at the control stream's rate, and the stream closed normally with 1000 after 50 s (request IDs 01a13abe-0469-79e1-89f7-ab3381fee484, 01a13abf-37bd-7f50-8ed2-07356c595123). The same list sent as keyterm= query params returns 400, so it is over the limit. Staging replies with ConfigureFailure / CONFIGURE_KEYTERM_LIMIT_EXCEEDED. The 7.13.0 text ("returns an Error") is also wrong for prod.
Fix in api/specs/asyncapi/schemas/schemas.listen.v1.yml (the keyterms description and the message-level "see keyterms" line), then regen:
Each entry is a plain term or phrase with no weights or intensifiers. The 500-token keyterm limit that
applies to the `keyterm` query parameter also applies to each update. Keep each list under the limit:
the server does not yet report over-limit updates consistently, so don't rely on an `Error` to catch one.
Heads-up for API-173: ConfigureFailure and ConfigureSuccess (both sent on staging) aren't in the Listen V1 response union, so the Python client parses them as None. Add both messages to the spec before API-173 reaches prod.
What I checked:
- Does it break existing code? No. Runtime
__all__is identical across 10 packages (root 453 names), all resolvable, and no signature changes. - Did the patches survive? Yes. pytest with WireMock in Docker: 1,075 passed, 4 skipped. mypy src + tests/typecheck and ruff check are clean.
- New
pydantic_utilities.pyfreeze: documented in AGENTS.md, matches pydantic 2.14.1 in the lock. The lock refresh is dev-only (pyproject unchanged).
|
Addressed in df141bc.
The API-173 response-union follow-up is already covered by deepgram-docs#1284, which adds |
|
@dg-coreylweathers Requesting re-review. The keyterm-limit correction is now in df141bc and is backed by source-of-truth deepgram-docs#1287. The generated model and Params docstrings match that source exactly.\n\nFocused validation passed: |
dg-coreylweathers
left a comment
dg-coreylweathers
left a comment
There was a problem hiding this comment.
Requesting changes. One item from my first review is still open, and production has changed since.
What this PR does: regenerates the Python SDK and re-applies every manual patch. The only change a developer sees is the docstring on keyterms in Listen V1 Configure, the message that swaps keyterms during a live stream.
[B1] The docstring says the server doesn't reliably report too-long keyterm lists. Production now reports every one. On a prod stream today, an update with 250 keyterms got ConfigureFailure / CONFIGURE_KEYTERM_LIMIT_EXCEEDED in 0.08 s, the stream kept transcribing, and a valid update got ConfigureSuccess (request ID 01a1461e-dc44-7d20-bff9-12531ba32c86). The df141bc wording also has no source: deepgram-docs#1287 was closed unmerged, and docs main still says the stream closes with 1011, so a regen from main today brings that back. Fix: once deepgram-docs#1284 merges, regenerate from it.
Should-fix, same PR if possible: ConfigureSuccess and ConfigureFailure aren't in the response union in listen/v1/socket_client.py:26-28, so both reach callers as None (also true in 7.13.0, and the file is frozen, so a regen won't add them). reference.md:4989 still describes InvalidConfigureMessage errors and a stalled stream.
What I checked:
- Did the patches survive? Yes. 50 patch markers present, no
.bakfiles, the one new freeze is documented. pytest 1,022 passed (non-wire), mypy and ruff clean. - Does it break existing code? No. No public names removed; the lock changes are dev-only.
- Does it conflict with #789 (
send_raw)? No. It merges cleanly in either order and keepssend_raw.
|
Addressed in 4b694a6.
Validation: poetry run pytest (1,077 passed, 4 skipped), poetry run mypy src tests/typecheck, Ruff on the affected Python files, and git diff --check. |
|
Addressed the follow-up review findings in 66c64b8 and 2febf66.
Final independent DevRel re-review: approve. Validation: poetry run pytest (1,079 passed, 4 skipped), mypy, Ruff, poetry check --lock, and git diff --check. |
dg-coreylweathers
changed the title
dg-coreylweathers
left a comment
dg-coreylweathers
left a comment
There was a problem hiding this comment.
Approving.
What this PR does: regenerates the SDK and adds typed ListenV1ConfigureSuccess / ListenV1ConfigureFailure replies for Listen V1 send_configure, which 7.13.0 delivers as None. The models are hand-applied from deepgram-docs#1284 and frozen until a regen consumes it.
What I checked:
- Are my earlier findings fixed? Yes. Live nova-3 stream (request 01a15418-d04a-7b32-9483-c3cc951d31bf): a valid update came back as
ListenV1ConfigureSuccess, a 250-keyterm update asListenV1ConfigureFailure/CONFIGURE_KEYTERM_LIMIT_EXCEEDED, and transcripts kept arriving. The docstrings and reference.md describe exactly that. - Do the hand-written models match #1284? Yes: same fields, required set and
typevalues. The open #1284 feedback keepsListenV1Error.code, which this PR also keeps. - Can a new type swallow an existing message? No. Every Listen V1 frame type parsed to its own class; the new tests fail when the union entries are removed.
- Will the release notes carry it? Yes. The title is now
feat(regen): …, so the squash commit cuts 7.14.0 with a changelog line. - CI green on 3.10–3.13; mypy and ruff clean.
Fixed in 1826f25: the async reference.md snippet now catches asyncio.TimeoutError so its timeout message fires; ListenV1ConfigureFailure.code lists the four rejection codes; the AGENTS.md entry for listen/__init__.py records the new exports so the next regen re-applies them.
Merge note: whichever of this PR and #789 merges second should add send_raw to the AGENTS.md patch line for agent/v1/socket_client.py.
Catch asyncio.TimeoutError in the async reference snippet, list the ConfigureFailure codes in the code docstring, and record the Configure acknowledgement re-exports in the frozen listen barrel entry. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1826f25 to
da38cbb
Compare
🤖 I have created a release *beep* *boop* --- ## [7.14.0](v7.13.0...v7.14.0) (2026-10-20) ### Features * **Voice Agent:** Send protocol-transparent control frames with sync or async `connection.send_raw(...)`. Dictionary payloads are serialized without model validation; pre-serialized JSON strings are sent unchanged. * **Listen V1:** Receive typed `ListenV1ConfigureSuccess` and `ListenV1ConfigureFailure` responses after `connection.send_configure(ListenV1Configure(...))`, including failure codes for unsupported or over-limit keyterms. ### Bug Fixes * **Voice Agent:** Clarify ForceEndTurn availability for hosted and self-hosted deployments. The example now reports `FORCE_END_TURN_UNSUPPORTED` and waits for the final outcome before closing the connection. ## Validation - Source PR CI passed across Python 3.10 through 3.13. - #803: `poetry run pytest` passed with 1,075 tests and 4 skips; mypy and Ruff passed. - #789: targeted socket-client tests, mypy, and Ruff passed. - #788: ForceEndTurn regression coverage passed. --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Greg Holmes <greg.holmes@deepgram.com>
2 participants
Summary
Compatibility
Validation
Full ruff check has 57 pre-existing issues in examples and manual tests.