异步视频任务为何无报错却交付失败

用户付了钱，页面却一直转圈，后台没有报错，任务也没有失败记录。作者运营一个图片转视频工具，在首月约 1,400 个任务中，发现约 6% 没能以可用形式交到用户手里。问题分散在超时、回调、文件校验和重复扣费等环节。

这篇最有用的结论是：异步任务的可靠性，要看它能不能走到明确结局。作者补齐状态记录、主动查询、幂等和积分账本后，次月用户可见的失败率降到不足 1%。其中的设计，适合用来检查那些「请求早就返回，结果还在后台跑」的业务。

为什么没有报错，任务还是丢了

这个工具的流程并不复杂：上传照片、选择运动风格、进入队列、调用渲染服务商、等待 webhook，再交付视频。

麻烦在于，每一步都可能只完成一半。例如，服务商已经开始渲染，本地进程却崩了；或者视频已经生成，通知完成的 webhook 没收到。本地没有异常可报，用户也没有结果可拿。

作者最初只用 pending 和 done 两种状态。它们能表示「还没完成」和「已经完成」，却无法区分正在排队、正常渲染、通知丢失和任务失联。后台看到几个慢任务，用户看到无限加载，两边都缺少判断依据。

改造后，作者把主要状态拆成 queued、rendering、delivered、failed 和 dead，并给每次状态变化记录时间戳。一个任务在 rendering 停留九小时，至少应该触发检查，不能继续被当作普通慢任务。

更关键的是执行顺序：先把任务记录写入数据库，再调用服务商。

这样，即使进程在两步之间崩溃，本地仍有一个 queued 任务，扫描程序可以接手。旧顺序则可能留下一个正在外部渲染、本地完全没有记录的任务，连补救入口都找不到。

能被恢复的任务，首先得有一条持久化记录。

不过，原文列出的五个主要状态并非完整状态机，后面还出现了 checking 和 retry。它们是独立状态还是内部处理阶段，作者没有说清，实际实现时需要补齐转换规则。

webhook 负责及时通知，扫描负责找回结果

作者曾经把超时设为 45 秒，依据只是「感觉差不多」。实际正常渲染经常超过这个时间，于是本地宣布失败，服务商却还在后台继续工作。

这里混淆了两个事实：请求没有按时返回，以及任务已经执行失败。前者只能证明当前不知道结果。

作者随后调整了两处：超时阈值根据真实渲染耗时分布设置，取高于第 99 百分位的位置；超时后进入 checking，由另一个 worker 查询服务商状态。原文没有给出调整后的具体秒数，不能把 45 秒当成推荐配置。

webhook 丢失也需要相同的补救思路。一次周五晚上的部署，让回调接口面对未测试过的载荷结构时返回 500。服务商重试几次后放弃，到周一早上，38 个任务卡在 rendering，实际上视频早已生成。

作者因此加入每十分钟运行一次的 sweeper，也就是定期扫描并补救遗漏任务的程序。它寻找超过预期处理窗口的任务，主动向服务商查询状态。webhook 继续承担及时通知的职责，扫描程序负责捡回没有收到通知的结果。

这套方案有个现实前提：服务商必须提供可查询的任务状态，本地也必须保存足够的关联信息。若只能提交请求、无法查询，原文这条恢复路径就走不通。

告警也随之调整。一个卡住的任务可以先交给自动恢复，一小时出现十个卡住任务则按事故处理。作者后来主要关注失败率和死信队列增长，避免手机被重试本来就能修复的单次失败刷屏。

重试、交付和扣费，必须放在一起设计

恢复任务之后，作者又遇到了重复执行：扫描程序已经重试并交付，迟到的 webhook 才到达，两条处理路径最终造成同一个视频被收费两次。

补救办法是给每个业务任务分配一个幂等键，创建时生成，随任务记录持久保存，整个生命周期都使用它。收费、服务商调用和交付在执行前检查这个键；重复交付则返回第一次的结果。

幂等的直白解释是：同一件事收到两次执行请求，也只能产生一次业务效果。这里最容易漏掉的是，幂等键属于任务，不能每次重试都重新生成。

但原文只讲了原则，没有说明如何处理并发。两个 worker 同时检查到「尚未交付」，仍可能一起执行。唯一约束、事务或其他并发控制，以及服务商是否支持幂等请求，都需要在实现中进一步确认。

交付本身也要重新定义。原先只要文件存在、下载链接可用，任务就会进入 delivered。用户拿到的却可能是截断文件、几帧黑屏，或者损坏的容器。

作者增加了文件大小、容器解析和时长校验，要求视频时长与任务要求在小范围误差内一致。校验失败就进入重试，只有通过后才算交付。这一步增加了几秒钟，但据作者描述，消除了一整类损坏视频工单。

积分系统随后改为三步处理：

• 创建任务时执行 hold，先冻结积分。
• 验证交付后执行 settle，确认扣除积分。
• 最终失败时执行 release，自动释放冻结积分。

每次冻结、结算和释放都有独立账本记录。任务耗尽重试次数后进入死信队列，保留完整历史，释放积分也是进入该队列的一部分。作者把这一节称为 hold, settle, refund，正文描述的失败补偿则是释放已冻结的积分，不能直接理解为所有支付渠道都已实现原路退款。

任务只有交付成功或明确失败并退回额度，才算真正结束。

我的判断

这篇说得最对的地方，是把用户等待、任务状态和资金处理连成了一件事。单纯增加重试，只能提高再次执行的机会；如果没有幂等，它也会提高重复收费的机会。作者确实踩过这个坑，随后才补上完整约束。

和只依赖 webhook 相比，主动扫描给了系统第二条获知结果的路径。代价也明确：额外查询、恢复延迟，以及服务商接口额度的消耗。十分钟是作者采用的间隔，是否适合自己的业务，要结合等待容忍度和接口限制判断。

输出校验同样有边界。容器能解析、大小合理、时长正确，不代表画面一定符合要求。作者提到过黑屏问题，但没有展示画面内容检测，也没有证明这些检查能识别所有黑屏视频。这里能确认的是增加了文件和时长校验，不能扩大成完整的视频质量保证。

数据方面，首月约 1,400 个任务、约 6% 用户可见失败，改造后一个月降至不足 1%，是作者报告的结果。原文没有给出次月任务量、流量构成、服务商变化或对照实验，因此这是有具体案例支撑的工程经验，不能据此认定每项措施各自带来了多少改善。

剩余失败中，多数是确实无法渲染的任务。它们现在会明确失败并退款，不再无限转圈。这种变化同样有价值：可靠系统需要允许失败，并让失败有解释、有补偿。

能拿来做什么

• 给现有异步任务补一张状态转换表，明确每个阶段的进入条件、时间戳、最长等待窗口和补救动作。前端根据这些状态展示排队、处理中、正在确认结果或已失败，避免一个加载动画覆盖所有情况。
• 如果 Node 服务接入外部渲染任务，先持久化本地记录，再发起调用，并保存外部任务标识。接到 webhook 后更新状态，同时保留定期查询路径，让服务重启和通知丢失后仍有机会恢复。
• 在增加自动重试之前，先确认同一个业务任务是否始终使用同一个幂等键，并检查收费、外部调用和交付三个环节如何防止并发重复执行。超时则先查询状态，避免贸然重复提交仍在运行的任务。
• 对按任务收费的生成业务，把产物校验作为结算条件，把最终失败补偿纳入任务收尾流程。监控优先看超时积压、失败率和死信增长，让告警对应需要人介入的问题。