Skip to content

fix(api): log ffmpeg stderr when a streamed render fails - #297

Merged
thcp merged 1 commit into
mainfrom
fix/mixdown-stderr-logging
Jul 17, 2026
Merged

fix(api): log ffmpeg stderr when a streamed render fails#297
thcp merged 1 commit into
mainfrom
fix/mixdown-stderr-logging

Conversation

@thcp

@thcp thcp commented Jul 16, 2026

Copy link
Copy Markdown
Collaborator

Closes #280. Phase 1 of #272 — plan: #272 (comment) (PR-1D).

What

_stream_ffmpeg (mixdown export, stem region trims, stem MP3 region, video mux) sent stderr to DEVNULL. If ffmpeg died mid-stream, the user downloaded a truncated file under an already-committed HTTP 200 — and the failure left no trace anywhere.

  • stderr → bounded 30-line tail via a drain task (draining is mandatory once stderr is a pipe; a full pipe would deadlock ffmpeg).
  • On non-zero exit after natural EOF: one WARNING with per-endpoint context (mixdown job=… ext=… stems=…) + the stderr tail.
  • Client-disconnect kills stay silent — they're expected. The discriminator is stdout EOF, not returncode (which stays None until wait() reaps the child even when it already exited — caught by the new test, fixed).

Testing

  • New async unit tests driving _stream_ffmpeg with a Python stub subprocess: failure logs context + stderr tail while still delivering the partial stream; clean exit logs nothing. Cross-platform, no ffmpeg needed.
  • Existing endpoint tests (mixdown/region/flac/video happy paths with real ffmpeg) unchanged and passing.
  • Full suite: 153 passed; ruff check + ruff format --check clean.

🤖 Generated with Claude Code

Streamed ffmpeg renders (mixdown export, region trims, stem MP3, video
mux) sent stderr to DEVNULL. When ffmpeg died mid-stream the client
received a truncated file with HTTP 200 already committed -- and no
trace of the failure existed anywhere, making "my export is broken"
reports unsolvable.

stderr is now drained into a bounded tail (mandatory anyway once it is
a pipe -- an undrained full pipe would deadlock ffmpeg) and logged at
WARNING with a per-endpoint context (job id, format, stems) when the
process exits non-zero. Kills we initiated on client disconnect are
expected and stay silent; EOF-then-nonzero is the failure signature,
since returncode stays None until wait() even for an exited child.

Closes #280
Comment thread tests/test_stems_api.py Dismissed
@thcp
thcp merged commit a666b39 into main Jul 17, 2026
8 checks passed
@thcp
thcp deleted the fix/mixdown-stderr-logging branch July 17, 2026 00:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Mixdown ffmpeg failures stream silently corrupt files

1 participant