LLM processor 空输入时 ThreadPoolExecutor(max_workers=0) 崩溃：极短音频（12s）转录必失败且重提交无法恢复

[zj1123581321]

结论

三处 LLM processor 用 max_workers = min(len(输入列表), 配置上限) 算线程池大小。
输入列表为空时算出 max_workers=0，ThreadPoolExecutor(max_workers=0) 直接抛
ValueError: max_workers must be greater than 0，任务在 LLM 阶段被判 failed。

这是确定性缺陷，与网络/服务状态/负载无关：同一个任务重新提交多少次都会以同一行错误失败。
生产上已经这么失败过两轮（2026-08-12 首次、2026-10-06 重提交复现）。

证据（生产实测，2026-10-06，n305 video-transcript-api 容器）

VTA 任务 task_ac8c5370bae3462ba9cd2be6ba018003，来源 live-recorder 任务
9a4d28020d5348f788bfe33932ea226e（音频时长 12 秒，标题「183冯律」）：

[perf] task_ac8c5370bae3462ba9cd2be6ba018003 | llm_processing: 2770ms (FAILED: max_workers must be greater than 0)
ERROR llm_ops._handle_llm_task:918 - LLM任务处理异常: task_ac8c5370..., 错误: max_workers must be greater than 0
cache_manager.update_task_status:2470 - 任务状态更新: task_ac8c5370... -> failed
terminal_status.finalize_terminal_status_and_notify:101 - terminal CAS won: task_ac8c5370... -> failed
[perf-summary] task_ac8c5370... | total: 7839ms

ASR 阶段本身是成功的（日志有 转录完成，生成文件: [...]），死在 LLM 阶段。
12 秒音频转出的文本为空 → 零分段 → min(0, 10) = 0。

该任务在 live-recorder 侧的表现：2026-10-06 重新提交后仍失败，vta_status 回到
confirm_timeout，页面显示「转录失败」。录音文件本身完好（0.4 MB，12 秒）。

缺陷点位（origin/main @ d968df8，行号实测）

文件	行	表达式	空输入可达性
llm/processors/plain_text_processor.py	420	min(len(segments), self.config.concurrent_workers)	已实测复现
llm/processors/speaker_aware_processor.py	970	min(len(chunks), self.config.calibration_concurrent_limit)	代码路径等价可达：normalized_dialogs 为空 → DialogSegmenter.segment([]) → chunks=[]（speaker_aware_processor.py:252），未实测
llm/processors/notes_processor.py	551	min(len(mapping.slices), self.config.notes_concurrency)	未确认，取决于章节映射能否为空

三处都在 ThreadPoolExecutor(max_workers=max_workers) 之前没有空列表守卫。

影响面

触发条件是「转录文本为空」。真实来源不是罕见的格式损坏，而是极短录制：
live-recorder 用户中途停止 / 临场切 mode 会产出几十秒碎片，其侧有
vta_min_duration_s（默认 120s）门槛，但本仓 API 侧没有对应门槛，直接
/api/transcribe 提交或 recorder 门槛被调低都会把空文本送进 LLM 阶段。

后果：任务永久失败且无法通过重提交恢复——用户能拿到的只有一段没有文字的录音。

建议修法

空输入时在该函数内直接返回与空输入同构的空结果（例 _calibrate_segments 返回
([], [])），不建池、不 submit、不打 LLM 请求；非空路径的并发行为、分段顺序、
contextvars.copy_context().run 传播与日志一律不变。

不建议改写成 max(1, ...)：那只是让空输入白建一个空线程池，语义仍然错。

附：另一批「转录文件失败」历史样本今日重提交已全部恢复

live-recorder 生产库有 23 个 vta_status=confirm_timeout 的历史转录失败样本，
其中 4 个的错误是 转录文件失败: data/temp/task_xxx/xxx.mp4（VTA 侧 ASR 阶段失败）。
2026-10-06 抽样重提交 60ffbf1bb460487094768504e0a6aa6d（8815.69 秒音频）：

transcription_deadline duration=8815.69 value=35382.8
capswriter_start attempt=1/5 media=.../强哥本人号.mp4 duration=8815.688667 deadline_total=35382.754668
capswriter_done ... processed=4520.1s ...
→ 任务完成

即当前版本能拿到时长、给出 4 倍实时预算，这批历史失败在今天的链路上不复现。
与 #170 描述的「recorder:// 路径时长预算恒失效」相关，但本次实测拿到的是
duration=8815.69（非 unknown），说明该路径当前已能取到时长——修 #170 前建议先确认
线上镜像是否已含相关改动，避免按过期机制排查。

[zj1123581321]

更正（2026-10-06 03:15 之后的实测，追加，不改上文）

上文「附：另一批『转录文件失败』历史样本今日重提交已全部恢复」这句不准确，在此更正，
以本条与 #181 为准。

live-recorder 生产库 23 个历史转录失败样本，2026-06 起的全部集中在 2026-10-06 重提交：

结果	数量	说明
成功（vta_done=1，页面显示转录完成）	21	含全部 4 个「转录文件失败」中的 3 个（8815s / 9388s / 9864s）
仍失败，原因 = 本 issue 的 max_workers=0	1	9a4d2802（12 秒音频）
仍失败，原因 = ASR 上传 idle_timeout	1	787644a0（17502 秒 / 494 MB）→ 详见 #181

即：4 个「转录文件失败」样本中 3 个今天恢复（这部分结论成立），第 4 个
787644a07c9348b588d4b84e60336ae8 今天两次提交仍失败，且 2026-10-03 那次也是同一现象——
它的根因不是 ASR 阶段偶发抖动，而是超长音频在上传阶段被 300 秒 idle 超时打死，
已单独开 #181 跟踪，不要按「历史故障已自愈」结案。

上文关于 #170「recorder:// 时长预算恒失效、读到的 duration 应为 None」的推论，
在这批实测里没有复现：所有样本日志都是
duration=<真实值> deadline_total=<真实值>*4+120（如 17501.673354 / 70126.693416、
8815.688667 / 35382.754668），没有出现 duration=unknown fallback=sdk_auto。
#170 若仍成立，其机制描述需要重新取证。

[zj1123581321]

已由 #180（合并提交 4e1be78，作者 @Fire162）修复：三处 processor 空输入直接返回空结果，不建线程池。终审结论：空文本任务终态为 success（llm_ops 成功 CAS → 任务完成通知）。完整门禁（含模型主审）在同仓镜像 #183 上对同一提交 6718bae 全绿。非阻塞遗留另开单跟踪。

[zj1123581321]

已部署到 n305（2026-10-06 14:01 CST）：镜像 ghcr.io/zj1123581321/video-transcript-api@sha256:378c4d5b497cbe56dc039609e491b1d33612a848b84eb8c0a55b6439950e6b36（GIT_SHA=4e1be78b7fcf），容器 running healthy，容器内已含空输入守卫，/livez 200。回滚点 sha256:fbdd54646f236fa3b0f8eb3c007d232ddc4e2bcd1730a458631a4310c86c7e92。待 live-recorder 任务 9a4d2802 重新转录验证。