Repository navigation
chore(regen): clarify Listen V1 keyterm limits - #803
GregHolmes wants to merge 7 commits into
Conversation
|
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
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.
Summary
Compatibility
Validation
Full ruff check has 57 pre-existing issues in examples and manual tests.