内容纲要
概要描述
任务流失败后，直接点击“重跑”可能重新执行已经成功写入的数据；直接选择“强制错误恢复”又可能绕过本应检查的依赖。本文说明如何先判断操作是否适用，再选择恢复范围，避免将“失败重试”“错误恢复”和“整流重跑”混为一谈。
详细说明
1. 固定本次要处理的记录
进入“运维 → 调度任务”，定位工作区、任务流和调度时间，记录执行ID、执行版本、执行模式、当前状态与失败任务。默认时间筛选为今天，处理历史记录时先扩大时间范围。不要只根据任务流名称或顶部成功率选择记录。
2. 先检查能不能恢复
- 错误恢复适用于失败、阻塞的任务流执行记录；任务流重跑要求原记录已进入终态。
- 任务流未发布、尚未执行结束或依赖策略已经变化时，文档列为不支持相应运维操作的场景，先停止，不用强制操作试探。
- 对比历史执行版本与最新版本，确认任务增删、依赖关系、调度周期与参数是否改变；重跑／错误恢复使用最新版本，不等于按历史版本原样再执行一次。
- 跨任务流操作还要检查关联的最新执行记录、当前调度时间是否仍属于最新cron的调度集合，以及下游是否仍在运行。
3. 按目标选择最小范围
| 目标 | 优先评估的操作 | 必须知道的影响 |
|---|---|---|
| 仅补做失败／阻塞链路中的相关任务 | 错误恢复当前 | 不重新计算所有已成功任务；生成新的关联记录 |
| 上游修正后，下游相关结果也必须重算 | 错误恢复当前及下游 | 其他上游分支的条件仍需满足，下游运行中可能阻止操作 |
| 所有任务都必须按最新配置重做 | 重跑当前 | 全部任务重跑，需评估重复写入和覆盖范围 |
| 当前与下游都必须全量重算 | 重跑当前及下游 | 影响更大，不应作为默认修复按钮 |
Workflow不保证业务数据幂等性。执行前由业务负责人确认目标分区／主键、写入方式、重复执行影响及恢复点。不能把“强制”理解为修复依赖或保证安全；它会忽略执行条件，但不保证所有下游分支自动满足。
对于偶发失败、希望后续自动重试的任务，另见TDS 调度任务添加错误重试；这与对已有失败记录做错误恢复不是同一流程。
4. 检查结果，而不是只看按钮成功
操作完成后，找到新生成的关联执行ID，核对调度时间仍对应原业务批次、实际执行时间为本次操作时间、实际执行版本符合预期，并检查本次被重新执行的任务集合及数据结果。运维统计可能按最新关联记录统计，历史记录仍保留，不能把失败计数减少理解为原失败记录被删除。
其他信息
任务依赖关系类型说明用于判断边的成功／失败／完成条件，不替代对本次跨流依赖和恢复范围的核对。未确认幂等性、拓扑差异或执行条件时，保留记录和错误文本交支持处理，不直接修改元数据库状态。