fix(types): make AutohighlightResult.rank Optional to tolerate missing field#207
Open
tsushanth wants to merge 1 commit into
Open
Conversation
…g field Closes AssemblyAI#148. The Auto Highlights API has been observed in production to return individual `auto_highlights_result.results` entries with no `rank` field set. The SDK currently declares `rank: float` as required, so the Pydantic validator raises a `ValidationError` while parsing the overall `TranscriptResponse` — turning a missing-field-on-one-entry into a hard failure that loses the entire transcript (text, utterances, words, sentiment, every other audio-intelligence result). Make `rank` Optional with a default of `None` so a missing rank parses through cleanly. The absence is observable to callers via `rank is None` — no silent default-value substitution. The change is narrowly scoped to the single field surfaced by the reporter. The other fields on `AutohighlightResult` (count, text, timestamps) remain required. Regression test deletes `rank` from the first highlight in the mock response, asserts the TranscriptResponse parses, the affected entry's rank is None, and other entries still have their rank set. Verified that the new test fails on master (the existing required-rank contract) and passes on this commit.
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
Closes #148.
The Auto Highlights API has been observed in production to return individual
auto_highlights_result.resultsentries with norankfield set. The SDK currently declaresrank: floatas required, so the Pydantic validator raises:The error is raised while parsing the overall
TranscriptResponse— so a missing-field-on-one-entry becomes a hard failure that loses the entire transcript (text, utterances, words, sentiment, every other audio-intelligence result), not just the affected highlight.Fix
class AutohighlightResult(BaseModel): count: int - rank: float + rank: Optional[float] = None text: str timestamps: List[Timestamp]A missing
rankparses through cleanly and the absence is observable to callers viarank is None. No silent default-value substitution; the field is genuinely missing, and the type reflects that.The change is narrowly scoped to the single field surfaced by the reporter. The other fields on
AutohighlightResult(count,text,timestamps) remain required — they haven't been seen missing in the wild and aren't speculative-loosened here.Tests
New regression test in
tests/unit/test_auto_highlights.py:Verified the test fails on master (current required-rank contract) and passes on this commit.
Test plan
pytest tests/unit/test_auto_highlights.py -v— 3/3 pass (2 existing + 1 new)rank: Optional[float] = Nonechange is reverted viagit stashAutohighlightResultfields (count,text,timestamps) still required — no inadvertent looseningOptional[float]letsrank is Nonework as expected at the call siteNotes for review
countortextOptional too as forward-compat) but kept the diff scoped to the actually-reported field. If the API is known to omit other fields in newer responses, happy to widen — let me know.