d91beef0fd314250d8d9b94de86dfea019a8bd96
11
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Palash Debnath
|
0268f43e7f |
fix(dub): keep language and media tools ready (#1679)
Fixes #1677 and #1678. Publishes first-run media tools to the live backend, provides precise cross-platform missing-process guidance, and keeps localized source-language selection available before transcription. Includes regression coverage and deterministic model-store test isolation. |
||
|
Palash DebnathandClaude Opus 5
|
41722afe3b |
refactor(launchpad): quieter, borderless design refresh (#1515)
* refactor(launchpad): quieter, borderless design refresh The launchpad carried decoration from an earlier direction: icon chips, corner-hung count badges, a permanently visible filled arrow, uppercase mono card titles, and a dotted stipple divider — plus a frame that had been invisible since the app-wide border tokens were zeroed. Rework it around what the borderless direction actually implies: - Feature tiles get a whisper-faint surface instead of a dead frame, and read as three bands (bare glyph + count / title + arrow / description). `--card-hue` is spent sparingly — the glyph at rest, the surface, count and arrow only once raised. Titles move to sans sentence case; counts are plain tabular numerals. Lift softened 4px -> 2px, coloured glow -> neutral shadow, plus an explicit focus ring and a staggered entrance. - Hero drops the boxed "646" pill and the filled A/B-Compare button for quiet type, with a hairline standing in for the separation. - Section labels trade the dotted stipple for a single fading hairline; rows are transparent until hover and reveal "Open" on hover/focus (it stays in the DOM, so AT and keyboard always reach it). - Hero, tiles, recent files, callout and project lists now share one 1180px column — previously only the top half was capped, so lists ran edge-to-edge on a wide display while the deck stayed centred. Two bugs found and fixed while doing it: - Buttons that had `border border-solid border-transparent` removed fell back to the UA default border and rendered a visible 1px outline. They now carry `border-0` explicitly. - `.lp-animate` used `animation-fill-mode: both`, so after the entrance it kept owning `transform` — and animation-origin declarations outrank normal ones, which silently killed the card hover lift. Now `backwards`, which still holds the from-state through the stagger delay. Also drops CSS the page has not rendered since #904: the cursor-spotlight layer, the breath ring, and the per-card waveform strip. Verified with headless renders at 1600/1280/940 and the empty state. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(dictation): decode Wayland portal signals and show the capture pill The GlobalShortcuts portal declares Activated/Deactivated as (o session, s shortcut_id, t timestamp, a{sv} options). We decoded the timestamp as u32, so zbus rejected every signal with Signature mismatch: got `(osta{sv})`, expected `(osua{sv})` and the press was dropped as an invalid signal. Registration succeeded and the desktop even reported the bound chord back, so the hotkey looked wired up while doing nothing at all — on every Wayland compositor, for the whole life of the feature (#1490). Decode the 64-bit timestamp, and keep the 32-bit spelling as a fallback so a non-conforming portal degrades to working rather than to silence. With presses arriving, the second half of the failure showed: nothing had shown the widget window since it became a hidden recorder host, so a capture ran with no pill on screen — and a mic or Accessibility failure rendered into a window nobody could see. Add show_dictation_pill, which bottom-centres the capsule on the monitor under the pointer and shows it without taking focus (Windows keeps SW_SHOWNOACTIVATE so paste still lands in the user's document), and call it from the widget for every state but idle. Wayland denies clients their own placement, so the compositor picks the spot there; the pill still appears. dispatch_dictation_capture now logs whether a press was emitted or queued — a press that reaches Rust and produces nothing was otherwise indistinguishable from one the compositor never delivered. Tests: portal signals decode at both timestamp widths (the 64-bit case fails before this change with the exact production error); pill placement centres, respects a second monitor's origin, and clamps rather than going off-screen; the widget shows for a state needing the user, stays hidden while idle, and never shows for a press that arrives while dictation is disabled. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * chore: sync in-progress workspace changes Uncommitted work already in the tree, checkpointed so the branch matches the local machine: - Remote GPU workers: join-from-the-app flow, one-time secrets, QR join codes, a Compute control in the status bar, and the device-list Workers panel (#1516) - Model Catalogue workspace, with Settings pointing at it - Settings sidebar search and keyboard navigation - Demo assets for dubbing, dictation and voice design, plus the scripts that render them - Backend: validation-error handling, ASR request-path degradation, and the accompanying tests - CHANGELOG entries for the above and for the Wayland dictation fix Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(tests): follow Engines to the Model Catalogue, and green the sweep - test_supertonic3 asserted the license gate points at "Settings" while the engine now names Model Catalogue → Engines, which is where the accept button actually lives. The assertion follows the move; what it pins is unchanged — the hint must name a place the user can reach it. - Carries the CJK allowlist entries for the rendered dub bundle (#1517) and the regenerated route snapshot for /workers/agent (#1516), both of which this branch inherits from the workspace sync. - docs/install/linux.md: the dictation capsule is bottom-anchored everywhere except Wayland, where the protocol gives applications no say in their placement. Documented rather than left as a surprise (CodeRabbit). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * ci: stop a flaky dependency fetch from failing green runs en-core-web-sm resolves to a direct GitHub release URL, and github.com intermittently answers `http2 error: refused stream before processing any application logic`. uv's own three retries all land within the same few seconds and fail together, so the whole job dies on a dependency that has nothing to do with the change under test — it cost #1518 and #1517 an otherwise-green run tonight. Two changes: back off between whole `uv sync` attempts, which is what actually clears it, and pass --no-sync to the pytest steps. `uv run` re-resolves the environment before running, so every test step was a fresh chance to hit the same fetch even though the install step had already synced — that is exactly how #1518 failed, in the isolated backend/tests step, with all 5467 tests already passed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * ci: one retry seam for every uv sync, not just the job that failed last en-core-web-sm resolves to a direct GitHub *release* URL rather than a package index, and github.com intermittently answers `http2 error: refused stream before processing any application logic`. uv's own retries all land inside the same ~10 seconds and fail together, so a job dies on a dependency unrelated to the change under test. Tonight that cost four otherwise-green runs across #1515, #1517 and #1518 — and the first fix only covered the Tests job, so the next failure simply moved to Smoke (Linux), which syncs separately. The fetch is per-job, so the fix has to be per-job: scripts/uv-sync-retry.sh backs off between whole attempts (15s, 45s, 90s) and every workflow that syncs now goes through it — ci.yml (tests + the platform matrix), release.yml, security.yml, evals.yml. It still fails loudly after four attempts, so a genuinely broken lockfile is not disguised as a flake. The Tests job also lacked the UV_HTTP_TIMEOUT / UV_HTTP_RETRIES the smoke matrix has always set, which is part of why it was the one that kept dying; it has them now. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * test(ci): pin the Intel-Mac contract by intent, not by command spelling test_ci_verifies_intel_mac_as_the_documented_remote_only_host asserted the literal line `run: uv sync --extra pockettts`, so routing every sync through scripts/uv-sync-retry.sh read as a broken Intel-Mac contract. The contract it exists to protect is that the pockettts extra installs ONLY on backend_supported legs — which the regex now pins, while leaving how the sync is invoked free to change. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * ci: keep every uv run out of the resolver, and bound the retry budget CodeRabbit, #1517: - `uv run` re-resolves before running, so the smoke suite, the worker-artifact tests, the release test run and the eval run were each a fresh chance to hit the flaky direct-URL fetch outside the retry loop. All of them pass --no-sync now; the environment is already synced by the step that owns the retries. security.yml's `uv run --with pip-audit` is deliberately left alone — it layers an ephemeral package rather than running the project's own tests. - The retry count multiplied uv's own budget (UV_HTTP_RETRIES=5 with a 120 s timeout on the smoke matrix). Three attempts and 60 s of total backoff outlast the refusals actually observed while staying well inside the jobs' timeout-minutes. - The Intel-Mac contract test pinned the smoke command literally too, so --no-sync tripped it exactly like the sync line did. Same fix: assert the contract (smoke runs only on backend_supported legs), not its spelling. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
|
5d6e05ef1b |
fix(errors): stop giving advice that cannot work (#1347, #1335, #1334) (#1374)
* fix(errors): a failed download is not a broken install (#1347, #1335) Two reports, one shape: the error text carried both a network cause and a downstream symptom, the taxonomy matched the symptom first, and the user was sent to fix something that was never broken. #1347 -- transcription failed with "transformers ASR pipeline failed to import (AutoFeatureExtractor) -- your transformers install is incomplete; reinstall with `uv pip install --reinstall transformers` ... Underlying: Cannot send a request, as the client has been closed." The install is fine. The pipeline was DOWNLOADING the feature extractor when the shared HTTP client closed underneath it (#880). Reinstalling transformers cannot fix a dropped connection, so the advice was not merely unhelpful -- it was work the user could repeat forever without succeeding. New MODEL_DOWNLOAD_INTERRUPTED class, checked before the import rules, requiring the httpx closed-client wording AND an import/transformers term so a bare closed-client error elsewhere is left alone. Its hint says the partial download resumes, since otherwise someone on a slow link assumes retrying restarts a multi-GB fetch. #1335 -- a cut TLS connection reached /generate as a bare 500 carrying `_ssl.c:1016`. core/failure.py has classified that since #1301, but /generate keeps its own taxonomy and never learned it, so it fell to the unrecognized-error catch-all. Added to the network signatures there: it is a dropped download, and the remedy is retry, not Flush. Both changes are orderings rather than new detections -- the cause now beats the symptom -- and both keep the case the original rule existed for: a genuinely broken transformers install still classifies as TRANSFORMERS_IMPORT, and a failed handshake is still distinguished from a cut connection. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(errors): a Windows paging-file limit is not out-of-memory (#1334) Same class as the two fixes already on this branch: advice that cannot work. The reporter asked, reasonably, whether OmniVoice needs an internet connection -- generation failed only when they disconnected, with a bare 500 carrying "The paging file is too small for this operation to complete (os error 1455)". Two separate defects made that unanswerable: 1. /generate matched it in _is_oom_failure and said "Try the Flush button to reload the model". Flush cannot help. The hint we had already written for this exact class says so outright -- "closing other apps usually won't fix it" -- but the generate path never consulted it. Now branched before the OOM check, naming the virtual-memory setting and stating plainly that it is not a network problem. 2. WINDOWS_PAGING_FILE_TOO_SMALL was absent from _CONTEXT_FREE_HINT_CLASSES, so on the raw-500 surface classify() identified it correctly and then attached nothing. The user got the OS sentence and no next step, despite the detailed remedy sitting in _HINTS. Its trigger (1455 with winerror/os error, or the literal phrase) is unmistakable, which is the bar that set requires. Both Python (`WinError 1455`) and Rust (`os error 1455`, from the safetensors mmap) spellings are covered, and a genuine CUDA OOM still gets the Flush hint. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(errors): tighten both new matches, and move the 1455 expectation CI caught a real one, and it was my process error: I ran the full sweep before adding the paging-file change, not after. tests/test_generation_audio_guard.py listed WinError 1455 among the OOM signatures and asserted it yields "ran out of memory / try Flush". The new branch routes it to the paging-file advice instead. That test's INTENT -- a genuine memory failure must never fall through to the unknown catch-all -- is preserved and still asserted; 1455 simply gets a more specific memory message now. Expectation moved, guard kept. Two over-broad matches tightened (CodeRabbit), both in the same direction: a rule that fires too widely replaces correct advice with advice that cannot work, which is the exact defect this branch exists to fix. * The TLS EOF wording is OpenSSL's, but nothing stops an unrelated component saying something similar, and calling a local fault a network problem sends the user to check a connection that was never involved. Now gated on an `ssl` marker; the real message always carries it. * MODEL_DOWNLOAD_INTERRUPTED required "client has been closed" OR "cannot send a request". The latter alone is generic enough to appear beside an unrelated import failure, where overriding TRANSFORMERS_IMPORT would swap correct reinstall advice for a "just retry" that never succeeds. Now requires the closed-client wording itself. Negative regression tests for both, plus the positive cases they must not cost us. Also resolves core.failure through a fixture at call time rather than importing it at module level, per the suite convention -- sibling tests reload these modules and a stale binding makes the file order-dependent. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: debpalash <nizam4103@gmail.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
|
324d417d27 |
fix(engines): mlx-audio no longer crashes on unsupported languages, error messages never leak raw exception internals (#977) (#993)
Root cause: MLXAudioBackend.generate() blindly truncated the full
language display name to two characters (language[:2].lower()),
assuming an ISO code — 'Dutch' -> 'du', which crashed Kokoro's vendored
pipeline's internal assertion (assert lang_code in LANG_CODES, (lang_code,
LANG_CODES)) for any language whose first two letters didn't coincidentally
match one of Kokoro's single-letter codes. The raw AssertionError's
tuple-containing-a-dict args then leaked straight into the user-facing
500 message via two stacked f"...{e}" formatters in generation.py.
- resolve_kokoro_lang_code() resolves against the AUTHORITATIVE
ALIASES/LANG_CODES table read from the installed mlx_audio package
(never a hardcoded guess), and only applies when Kokoro is the actual
active curated model — other curated models (CSM, Dia, Qwen3-TTS,
OuteTTS, ...) either ignore the kwarg or expect a different format, so
Kokoro's strict validation doesn't wrongly reject them. Unsupported
languages now raise a clear ValueError naming what Kokoro supports,
which generation.py already converts to a clean 400.
- _safe_exc_text() hardens both generic exception formatters in
generation.py: if any element of an exception's .args is a container
(dict/list/tuple/set), never interpolate str(e) raw — name the
exception type and point at the log instead. Protects every current
and future engine's generate() from leaking a raw container repr, not
just this one Kokoro assertion.
Co-authored-by: mergetest <test@local>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
|
||
|
|
ba4f64240a |
fix(engines): classify sherpa "model not set" as a config error, gate the engine on its model dir (#919) (#934)
A user selected the sherpa-onnx TTS engine and got a 500 that read "TTS engine stopped mid-generation. This usually means it ran out of memory. Try the Flush button…" — when the real cause was a pure setup problem: "OMNIVOICE_SHERPA_MODEL not set. Point it to a sherpa-onnx TTS model directory (containing model.onnx + tokens.txt)." Same misclassification class as #880/#893, which tightened the OOM catch-all on the generation path — but the engine-not-configured case still fell through to memory. Two layers, fixing the whole class: 1. Error classification (backend/api/routers/generation.py): a new `_is_config_failure()` recognizes "required engine model path / env var not set" over the whole exception chain (OMNIVOICE_* named with "not set"/"point it to"/"set omnivoice_…", sherpa's "no model.onnx found in", "not configured", "venv not found. set" for the dedicated- venv opt-ins). `_oom_friendly_reraise` checks it BEFORE the OOM branch and re-raises actionable setup guidance that names the variable, points at Settings → Engines, and never mentions memory or Flush. Generalizes to sherpa/Confucius4/dots/MOSS and any future env-gated engine. 2. Engine gating (backend/services/tts_backend.py): SherpaOnnxBackend ships no bundled model, so is_available() now gates on OMNIVOICE_SHERPA_MODEL (set + contains model.onnx) — like the other path-configured opt-in engines — returning False with an actionable reason instead of "ready", so the picker marks it unavailable-with-a- reason rather than selectable-but-broken. Added the copy-paste setup snippet for the Compat Matrix. Backward-compatible: a correctly configured OMNIVOICE_SHERPA_MODEL keeps the engine available. Tests (fail-before/pass-after): config-classification of the sherpa "model not set" error and the wider not-configured class (no "out of memory"/"Flush"); is_available gating on the env var + model.onnx and the setup-snippet registration. Fixes #919 Co-authored-by: mergetest <test@local> Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
|
6e600c48cb |
fix(generation): classify network/download failures — stop mislabeling every unknown error as OOM (#880) (#893)
A kittentts first-use HuggingFace download died with httpx's "Cannot send a request, as the client has been closed", and the generation error classifier's catch-all fallback told the user (CPU-only ~80 MB ONNX engine, 12 GB-VRAM box) they were OUT OF MEMORY and to press Flush — the wrong remedy for a network failure. Three-part class fix: - generation.py: new #880 branch (before the OOM hint) classifies httpx/requests transport failures — matched over the whole exception chain (type names like ConnectError/ReadTimeout plus stringified signatures like "client has been closed") — as a download/network problem with a retry/check-connection remedy. - generation.py (the real class bug): the OOM hint is no longer the catch-all. It now requires an actual OOM signature (typed OutOfMemoryError/MemoryError anywhere in the chain, or CUDA/MPS/CPU allocator wording); genuinely unknown errors surface as unrecognized with the underlying detail instead of a false "ran out of memory". - tts_backend.py: KittenTTS's first-use load retries exactly once with a fresh HF Hub client (huggingface_hub.utils.close_session()) on the specific closed-client failure — hub ≥1.x shares one global httpx client, and a closed one is recoverable, so the download self-heals instead of failing the generation. Fail-before/pass-after tests: classifier (closed-client message, wrapped httpx type names, unknown error, real OOM signatures incl. typed OutOfMemoryError, WinError 1455) + the retry helper (recovers once, walks the chain, no retry on unrelated errors, single-shot). Fixes #880 Co-authored-by: mergetest <test@local> Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
|
c5c57508b3 |
fix(device): fall back to CPU when the GPU arch is unsupported, not 500 every generate (#756) (#757)
* fix(settings): contain + tighten the whole Settings surface (measure cap, container-query stacking, wrap the shared rows) Two systemic issues drove 'too spread out' + 'elements go out of view' across many Settings pages: 1. Spread — .settings-content capped at 1280px, so on wide windows every label-left/control-right row left a huge void. Introduce a --settings-measure token (720px, macOS-like) + --settings-rail, and cap the content to it, left-aligned under the nav. One token now controls the reading width. 2. Overflow + bad responsiveness — the row stack break was a *viewport* media query (560px), but the 168px nav rail means a 760px-viewport window only has ~530px of content, so rows went side-by-side in a cramped box. Make .settings-content a container (container-type: inline-size) and stack on the CONTENT width via @container, keeping the viewport @media as a fallback for the .st-row instances used outside Settings (Splash/FirstRun/Dub/SetupWizard). 3. The shared .perfpanel__row (button/badge row reused by 6+ panels: RemoteBackend, HFMirror, LLMEndpoint, Pronunciation, MCPBindings, …) was an inline-flex with no wrap and no max-width, so it ran off the right edge — add flex-wrap + max-width:100% + min-width:0. Plus two rigid-width fixes that escaped the row cap: ApiKeys input min-width:220→0, Appearance scale floor. Frontend builds clean; tokens, @container query, and the wrap all verified in the emitted CSS bundle. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(settings): center the settings block + tighten measure (kill the lopsided right void) The capped content was left-aligned, so on a wide window everything jammed to the left with a dead empty third on the right (screenshot). Center the whole settings block (nav rail + content) as a unit via max-width + margin-inline:auto, and drop the measure 720→660 so label→control rows read denser. The cap is computed from the tokens (rail + gap + measure + page padding) so the content track lands exactly at --settings-measure. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(device): fall back to CPU when the GPU arch is unsupported, instead of 500-ing every generate (#756) get_best_device() called check_device_compatibility() and, on an unsupported compute capability, only LOGGED a warning then still returned 'cuda' — so the model loaded on a GPU whose kernels can't launch and every generate 500'd with 'CUDA error: no kernel image is available for execution'. Both a too-old card (Pascal sm_61, GTX 10-series) and a too-new one (Blackwell sm_120 on pre-cu128 wheels) hit this. Now an unsupported arch falls back to CPU (works, just slower) with a clear warning; OMNIVOICE_FORCE_CUDA=1 overrides. Belt-and-suspenders: _oom_friendly_reraise classifies a raw 'no kernel image is available' as an unsupported-GPU error (switch to CPU / install matching torch) rather than the OOM/Flush message. Tests: get_best_device → cpu on incompatible, stays cuda on compatible, honors the force override; reraise gives the actionable GPU message, not OOM. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * test(device): patch detect_host_caps via string path so the #756 fallback test is full-suite robust The first version aliased the import + inserted backend on sys.path, which patched a module copy get_best_device's local 'from core.device_caps import detect_host_caps' didn't resolve in the full suite (passed alone, failed in CI). Use the string-form monkeypatch target; verified passing alongside the other device/model tests. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * docs(changelog): fold #757 device-fallback entry into [0.3.8]; drop the merge's stale [Unreleased] dupe --------- Co-authored-by: mergetest <test@local> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
|
a9948de99e |
fix(generate): classify [Errno 32] Broken pipe as a lost-pipe error, not OOM (#715) (#722)
A BrokenPipeError surfacing from generation means the backend's stdout/stderr pipe to the desktop shell that launched it closed mid-render (an orphaned or relaunched backend) — not out of memory. _oom_friendly_reraise mislabeled it "ran out of memory — try Flush," which never helps. Add a BrokenPipeError / [Errno 32] branch (same pattern as the #705 WinError-193 and #437 permission branches) that tells the user to restart the app instead. main.py already wraps sys.stdout/stderr to swallow EPIPE; this catches the C-level writes inside the native engine/torch that escape that guard. Regression test covers both the typed BrokenPipeError and a string-wrapped "[Errno 32] Broken pipe". Co-authored-by: mergetest <test@local> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
|
883a06e9c0 |
fix(generate): classify WinError 193 as a corrupt native component, not OOM (#705) (#706)
A synth failure from a corrupt or wrong-architecture native binary on Windows
([WinError 193] %1 is not a valid Win32 application — torch, ffmpeg, or a
bundled engine binary) fell through to the generic OOM message ('ran out of
memory — try Flush'), sending the user down a path that can't help.
_oom_friendly_reraise() now detects the WinError 193 / 'is not a valid Win32
application' signature (before the OOM fallback, joining the existing
torch.compile / decode-glitch / bad-instruct cases) and surfaces an actionable
'reinstall or repair that component; Flush won't help' message. Regression test
added.
Co-authored-by: mergetest <test@local>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
||
|
|
81a007552b |
fix(generate): classify a bad-instruct error as a 400, not a 500 "ran out of memory" (#664) (#665)
A user typed free-form prose ("Speak with high energy … like a podcast host")
into the voice-design instruct field and got a **500** whose message read "TTS
engine stopped mid-generation. This usually means it ran out of memory. Try the
Flush button …" — with the real cause ("Unsupported instruct items found …")
buried as the underlying error. The user is told to Flush for an OOM that never
happened; the actual problem is a rejected instruct.
Root cause: `_resolve_instruct` raises on unknown/conflicting instruct items, but
by the time the error reaches `_oom_friendly_reraise` it's no longer a bare
`ValueError` (a lower layer wraps it), so the route's `except ValueError -> 400`
guard misses it and it falls through to the generic OOM `RuntimeError`. v0.3.7
has had that guard since v0.3.6 yet still produced the OOM message — proving the
error arrives wrapped, so type-based detection is insufficient.
Fix: in `_oom_friendly_reraise`, detect the instruct-validation **message
signature** ("unsupported instruct items" / "conflicting instruct items" / "in a
single instruct") regardless of exception type and re-raise a clean `ValueError`,
so the route returns a **400 with the instruct guidance** instead of a 500 OOM.
This is version-independent and complements the client-side guard (#658/#612):
it also covers API/MCP callers and stored profiles whose instruct slips through.
Test: two cases in test_generation_audio_guard.py — a bare instruct `ValueError`
and one wrapped in a `RuntimeError` both reclassify to a ValueError without the
"ran out of memory" text; the generic OOM path is unchanged.
Closes #664
Co-authored-by: mergetest <test@local>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
||
|
|
b15acbaae9 |
fix(dub+generate): yt-dlp 403 player-client fallback (#625) + non-finite audio guard (#629) (#635)
Two independent fixes from issue triage; no version bump. #625 — yt-dlp 403 on the media download (some videos serve formats signature-protected to the default player client) is not transient, so the existing broken-pipe retry (#579) kept 403ing. The URL download now escalates the YouTube player client (tv → android → web_safari) on a 403 before giving up; a 403 no longer counts against the transient-retry budget. #629 — a numerical glitch in the model (seen on MPS) could leave NaN/inf samples that write an unreadable WAV; a downstream decode then failed with an opaque "ffmpeg returned error code: 183 / Invalid data", surfaced to the user as a misleading "ran out of memory". Sanitize non-finite samples to silence in _apply_effect_chain (single chokepoint, covers the raw path too) so the WAV is always decodable, and classify a decode/ffmpeg failure as unreadable-audio rather than OOM in _oom_friendly_reraise. Tests: 403 escalation order + success-on-alternate-client; NaN/inf sanitize + finite-passthrough + decode-error classification. Full suite 1851 passed. Co-authored-by: mergetest <test@local> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |