fix: stop failing transcode polling on unrecognized phase names - #11
Open
nate-kelley-buster wants to merge 1 commit into
Open
nate-kelley-buster wants to merge 1 commit into
nate-kelley-buster wants to merge 1 commit into
Conversation
Fixes TheBestMoshe#3 entry add, track upload, and track status all polled transcode status against a hardcoded allow-list of "in progress" phase names (queued/processing/transcoding, or queued/processing). Any other phase the API returned was treated as a terminal failure and the command exited immediately with "Transcoding failed with status: <phase>" — even though the file was still being processed. In practice the API emits more phases than the allow-list knew about ("analyzing", "downloading" both reproduced live), so most uploads failed instantly instead of polling through to completion, exactly as described in TheBestMoshe#3. ## Fix Invert the check: only treat a phase as terminal failure if it's explicitly "failed" or "error". Any other phase (known or not) is treated as still-in-progress and polling continues until the file reaches "complete" or the timeout elapses. Also bumped the polling timeout from 5 to 10 minutes across all three call sites, since the old timeout was sized around the old (incomplete) phase list and some files legitimately spend real time in earlier phases like downloading/analyzing before transcoding starts. ## Verification Reproduced against the live API: `entry add` on a real audiobook chapter failed immediately with "Transcoding failed with status: analyzing", then again with "status: downloading" after a partial fix. After this change the same file uploads and transcodes successfully end-to-end (56-minute file, "Transcoding complete"). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0182auKxRRCcLdZrBotvbJ6K
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
1 participant
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.
Problem
Fixes #3.
entry add,track upload, andtrack status --waitall poll transcode status against a hardcoded allow-list of "in progress" phase names (queued/processing/transcoding, orqueued/processing). Any phase outside that list is treated as a terminal failure and the command exits immediately:The file isn't actually failing — it's still being processed. The API evidently emits more phases than the allow-list accounted for. I reproduced this live and saw both
analyzinganddownloadingtrigger the false failure on otherwise-healthy uploads.Fix
Invert the check: only treat
failed/erroras terminal. Every other phase (named or not) is "still working," so polling continues until the file reachescompleteor the timeout elapses. This also matches the workaround already documented in #3 (upload with--no-wait, then polltrack status— which only "works" because polling for status separately doesn't hit this same bug on retry... except it does hit the same allow-list, so this fixes that path too).Also bumped the poll timeout from 5 to 10 minutes across all three call sites, since 5 minutes was calibrated assuming only 2-3 phases; real files now legitimately spend time in earlier phases (downloading, analyzing) before transcoding even starts.
Verification
Reproduced against the live API on a real 56-minute audiobook chapter file:
entry addfailed instantly withstatus: analyzing, thenstatus: downloadingafter a partial fix attempt.✓ Transcoding complete, entry added successfully) with no code changes other than this fix.