Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

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

未关闭
  • 哪里不对？
#4,058 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

@CasbaL 已经在做这个了。

开始于 2026年9月18日。

  • #4059 来自 @CasbaL —— 未关闭

评估

难度
4/5
预计耗时
3-5 天
新手友好度
38/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
活跃
技术栈
typescript
领域
backend

调研方向

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.

由索引模型根据 Issue 内容生成。

描述

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.

主要语言
TypeScript
星标
54.1k
派生
4.9k
平均合并
7 小时 29 分钟
30 天内合并 PR
778

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

heygen-com/hyperframes 的其他 Issue

查看 heygen-com/hyperframes 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。