视频生成还在排队，关掉页面会停吗
用 MiniMax 官方 V2 与 Nbility H3 接口说明异步视频任务的等待、取消和恢复，区分停止轮询、取消生成、删除记录与结果下载。
视频任务显示排队中，关掉页面、终止脚本或点一下“停止”，不一定会让服务器取消生成。客户端可能只是停止等待；任务已经受理后，会怎样继续，要看服务端是否提供取消接口，以及取消时任务已经走到哪一步。
本文于 2026 年 11 月 12 日读取 MiniMax 官方 V2 的查询文档、取消或删除文档，并对照本站 MiniMax H3 接口。这是任务管理说明，没有创建、取消或下载真实视频，也没有验证费用退回。
四个动作分开记
客户端提交后拿到任务 ID，只证明服务接受了一个任务。任务完成和本地文件保存，还在后面。
| 动作 | 实际改变什么 |
|---|---|
| 停止轮询／关闭页面 | 客户端不再继续查询 |
| 取消任务 | 服务端尝试停止尚可取消的工作 |
| 删除任务记录 | 按接口规则移除某条记录 |
| 下载结果 | 将已经生成的文件复制到自己的存储 |
模型仍可能在处理，而本地等待已经超时。此时保留 ID，稍后查询同一个任务即可；不要把“我没等到”改写为“服务端没有收到”。反过来，任务状态成功也不证明自己的媒体库已经存好了文件。
现有图片任务恢复文章也区分提交、查询和下载；这里新增的是视频取消和删除的状态限制，不把两套接口混写。
MiniMax 官方取消取决于请求到达时的状态
官方 V2 使用 DELETE /v2/video_generation/{task_id}，名称是“取消或删除”。它按服务端当前状态决定执行的动作：
| 官方 V2 状态 | 该 DELETE 的行为 |
|---|---|
queued | 取消，返回 action: cancelled；官方说明未开始处理、不收费 |
running | 不允许取消，返回错误 |
succeeded 或 failed | 删除任务记录，返回 action: deleted |
cancelled | 不允许，返回错误 |
不能从“界面刚才还显示 queued”推导这次取消一定成功。排队与运行之间会发生状态变化，查询和取消又是两次请求。最终以取消接口的实际响应为准；收到错误或请求结果不明时，先查现有任务，不自动重建。
删除成功记录也不等于撤销已经完成的生成、退费，或证明所有媒体副本已经清除。需要数据删除保证时，应另查服务条款和支持渠道，不能让一个任务记录接口承担它没承诺的含义。
官方接口和本站路径分别处理
MiniMax 官方 V2 查询路径为 GET /v2/query/video_generation/{task_id}，成功状态是 succeeded，结果在 task.content.url。本站 H3 文档使用 GET /v1/videos/{task_id}，成功状态是 completed，结果字段是 url。旧版 MiniMax 文档还有 Success 与 file_id 的写法，不能混用解析器。
| 当前读取的协议 | 查询成功状态 | 结果位置 |
|---|---|---|
| MiniMax 官方 V2 | succeeded | task.content.url |
| Nbility H3 | completed | url |
本站文档列出创建、查询、下载和媒体上传，本文未验证本站存在等价的取消或删除接口。不要把官方 V2 的 DELETE 路径粘到本站地址，也不要拿 Nbility Key 调用官方地址。
如果已有本站任务号，可以用下列只读查询；本文只做语法检查，没有发起真实请求。Key 从私密环境注入，响应保存在私有文件：
umask 077
export VIDEO_TASK_ID='YOUR_EXISTING_TASK_ID'
curl --fail-with-body --silent --show-error \
-H "Authorization: Bearer $NBILITY_API_KEY" \
"https://api.nbility.ai/v1/videos/$VIDEO_TASK_ID" \
--output video-task.json
本站文档建议每 5–10 秒查询，轮询程序还应设置总等待上限、尊重限流与退避。达到本地上限时，把状态记为“停止等待、结果未定”，不要擅自改成服务端 failed。
提交结果不明时，先找回同一个任务
发起创建前，给业务操作分配一个本地编号，保存请求摘要和发送时间；获得服务端 ID 后立即写入记录。至少分开记：
本地操作号：本次创作的身份
服务商／接口版本：用哪一套协议继续查询
服务端任务号：创建成功后返回的 ID
任务状态：未知、等待、运行或终态
文件状态：未保存、下载中、已校验
通知状态：是否已向业务系统交付本次完成消息
这些是建议记录的字段，不是本站提供了这个整套数据结构，也不是 POST 幂等承诺。本站 H3 文档明确不承诺用客户端 Idempotency-Key 去重独立创建请求。同一提示词也不能充当服务端任务身份。
若超时前没拿到 ID，保留时间与可用请求标识，到服务控制台或支持渠道查证。不能查明时，人工决定是否接受再次创建的风险。多层自动重试为什么会放大问题，可参见重试与故障切换。
下载和通知也要能够恢复
MiniMax 官方 V2 文档当前只允许查询最近 7 天的任务，并提示结果 URL 有时效。这个查询窗口不能套成本站保留期，也不能当成视频链接必然有效 7 天。及时保存自己的副本；下载失败先恢复下载，不重提视频生成。
结果 URL 可能属于独立媒体域名，不要默认附加模型 API Key。下载到临时文件后，核对内容类型、文件大小与媒体解码，再把它标为已保存。HTTP 200 或一个 .mp4 后缀都不够。
如果程序要向群或业务系统发送完成通知，用业务操作号与任务 ID 记录已处理事件，并让外部写入具备去重机制。一个本地“已发送”布尔值无法独自解决发送成功后进程崩溃的问题；恢复时要查询目标记录或使用目标系统支持的幂等标识，参见n8n 重跑与外部动作。
开始下一段视频之前，先确认上一段的任务身份、实际终态和文件副本。创作层面的连续编辑另见 Gemini Omni 视频工作流；换模型和换协议时，继续保留各自的查询、取消与保存规则。
