Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[Windows] Transient ffmpeg/ffprobe spawn failures (EBUSY/ETXTBSY) fail the whole render with a bare "spawn EBUSY" — no retry, no context

Aperta
#4,058 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@CasbaL ci sta già lavorando.

Dal 18/9/2026.

  • #4059 di @CasbaL — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
38/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
backend

Direzione di ricerca

Start by tracing the three spawn paths in packages/engine/src/utils/runFfmpeg.ts, packages/producer/src/services/audioExtractor.ts, and packages/producer/src/services/render/audioPadTrim.ts. Verify how each reports spawn errors, then check the surrounding test setup before defining coverage for transient retries and exhausted failures. Done means the affected Windows spawn failures retry with backoff and exhausted errors include the binary path, errno, and file-lock hint.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

triage/needs-triage
Describe the bug

On Windows, spawning the managed ffmpeg/ffprobe binaries can fail transiently with EBUSY/ETXTBSY when the executable file is briefly locked — overwhelmingly antivirus real-time scanning a just-written or just-executed exe, occasionally a lingering handle from a concurrent sibling invocation (a single render shares one managed ffmpeg binary across many stages: media probing, frame extraction, audio mix, encode).

When that happens, the whole render fails with a bare, context-free error and there is no retry:

Error: spawn EBUSY

We observed this repeatedly in an Electron integration of the producer: a Delivery transcode step used the same managed ffmpeg.exe seconds before the render pipeline started; the render then failed on its first ffmpeg/ffprobe spawn and the user-facing export was lost. Re-running the export afterwards succeeded — confirming the condition is transient.

Root cause

All three spawn sites surface the raw child-process error without classification or retry:

  • packages/engine/src/utils/runFfmpeg.ts — the spawn error arrives inside the ManagedChildProcess outcome (reason: "spawn_error", raw error).
  • packages/producer/src/services/audioExtractor.ts (runFFmpeg) — ffmpeg.on("error", reject).
  • packages/producer/src/services/render/audioPadTrim.ts (runFfprobeJson) — throws outcome.error raw.

Node reports these as Error: spawn EBUSY (with .code set), so neither the user nor the logs can tell which binary, which stage, or that the condition usually clears on retry.

Expected behavior
  • A transient file-lock spawn failure should be retried a few times with a short backoff — a fresh spawn almost always succeeds once the AV scan finishes.
  • When retries are exhausted, the error should name the binary and the errno, and hint at the usual cause.
Environment
  • Windows 11 x64 (applicable to any Windows host with real-time AV scanning)
  • Producer used via an embedded runtime, ~v0.8.40
  • ffmpeg.exe/ffprobe.exe resolved via managed binary paths
Proposed fix

A shared engine helper, withTransientSpawnRetry, that:

  • classifies EBUSY, ETXTBSY, EAGAIN, EMFILE, ENFILE as transient file-lock errnos;
  • re-runs the caller's existing spawn-and-wait flow with exponential backoff (250 ms base, up to 3 attempts) and logs each retry with the binary path;
  • enriches exhausted failures with the binary path, errno, and a "transient file lock (often antivirus real-time scanning)" hint;
  • wraps the caller's flow rather than the raw spawn() call, so a healthy spawn keeps its exact synchronous timing.

A PR is on the way.

Lingua principale
TypeScript
Stelle
54.1k
Fork
4.9k
Merge medio
7h 29m
PR unite (30g)
778

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di heygen-com/hyperframes

Tutte le issue di heygen-com/hyperframes

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.