等待异步任务真正完成

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

视频生成接口接收请求并返回 J3，状态 queued，产物还未可用。教学轮询预算为三次，服务支持按同一 job id 查状态。你需要区分接收、运行、终态和取得产物，不能把创建响应当视频。

具体做法

保存任务 id 与请求身份，按服务约定的间隔、限流和预算查询同一任务。completed 后再取产物并核对可用性；failed 报告真实错误；预算耗尽仍运行则交付可续查的 pending 状态。取消根据已约定规则和权限，不为了结束回复默默取消或新建任务。

反例

J3 创建成功就直接说视频已生成并发布。查询没及时完成就重复创建，或自动取消原任务，不保留 id。

改进写法

保存教学 J3，按服务契约最多查询三次并记录 queued/running/completed/failed。只有 completed 且产物已取得时才报告可用视频；failed 列错误。三次仍未完成则报告 pending、已查状态和 J3，方便续接，不再创建重复任务。取消遵守已给规则与授权；临时产物 URL 的有效性单独核对。

为什么这样改

接受任务说明服务开始处理，不能证明输出存在。任务身份与终态分开，让等待、失败和已取得产物都有明确证据，也避免重复创建带来成本和结果混淆。

如何验证

教学状态序列 queued→running→completed 后才取得视频；queued→running→running 则报告 pending；failed 不取成功产物。

检查所有查询使用 J3、预算有限且没有未授权发布，URL 可读不被当永久可用。本例不生成真实视频。

适用边界

实际状态名、间隔、取消和临时链接期限以当前服务为准。冻结来源的固定七天说明不是本篇当前保证；等待预算不能改变服务结果，也不替代产物检查。