依赖链如何自动停止、等待和重新调用？
走一遍完整的恢复状态机：停止与副作用处置、ODS 验证门禁、按依赖顺序自动重做、普通失败处理，以及 ODS 再次修复后的重新入队。
从「再跑一次」到自动恢复
依赖链如何自动停止、等待和重新调用？
影响范围已经圈定，接下来要把「8 个受影响实例」变成一次可控的恢复：先停止还在运行的任务并确认副作用，再验证 ODS 修复，最后按依赖顺序自动重新调用。整个过程几乎无人值守，但每一步都要有状态和日志证据。
为什么不直接手工把 8 个任务挨个重跑一遍？
核心概念
自动依赖调用（Dependency-driven Invocation）
重做不是逐个手工点击，而是由调度按当前有效的依赖关系在上游完成后自动调用下游。人工只处理验证门禁、失败处置和范围确认，不逐任务驱动执行。
第一步永远是止损：先停稳，再谈重做
事故确认时，DWS 商户汇总仍在运行。如果直接开始重做，正常调度与重做调度会同时操作同一条受控链路：可能重复写目标表、重复产生文件或外部副作用。正确顺序是先停止正在运行的受影响实例，确认停止与副作用处置，再把它们置为等待。
停止的范围由影响分析决定：只有受控实例需要停止，无关链路继续正常生产。调度器负责识别与阻断，不需要人工逐个判断哪些任务还在跑；这一段对应 5-3 的失败传播与停止语义。
- running → stopping → stopped：停止必须确认，不能假设已经停住。
- ready 但未开始的受影响实例直接阻断为 waiting，不执行。
- 正常调度与重做调度对受控任务互斥；无关链路不被误停。
ODS 验证门禁：验证不通过就不生成重做计划
停止之后不能立刻重做。重做的输入是修复后的 ODS 数据，而修复是否可信需要验证：分区是否到达、行数与控制表是否一致、主键是否唯一、引用是否可以解析。只要有一项不通过，平台就不生成重做计划。
这道门禁和不完整数据进入数仓之前的那道门禁是同一件事的两面：6-2 的规则、6-4 的证据都在回答「凭什么相信这份输入」。门禁不通过时，等待再次修复并重新验证，而不是带着不确定输入开始重做。
- 门禁通过 → 放行重做；不通过 → 保持等待并记录原因。
- 验证项必须有证据，不能用「应该没问题」代替。
- 重复验证是幂等的：修复后可以再次验证，不需要新的批次概念。
依赖链重做实验 · E3 停止、等待与自动重做
走一遍完整的恢复状态机
依次操作：停止受影响任务 → ODS 验证（可切换通过 / 不通过）→ 生成重做计划 → 执行重做。还可以打开「让 DWD 失败一次」的教学开关，观察失败如何按正常生产故障处理，以及 ODS 再次修复后如何重新入队。
正在加载交互实验…
自动依赖重做：上游先完成，下游自动被调用
计划生成后，平台按依赖顺序自动调用：接入 → 校验 → DWD → DWS 两支 → ADS → 消费方。人工不需要逐个点击「运行」，只需要在失败时按正常生产故障流程处理。这就是「调度自动按依赖调用」的含义。
重做过程中如果某个任务失败，它保持 FAILED 语义，下游停在等待；已经成功的上游保持成功，不会被级联清空。修复失败原因后从失败点继续，而不是整条链路从头再来。
- 依赖顺序由当前有效的血缘与调度依赖决定，而不是复制历史执行顺序。
- 重做失败与正常生产失败同语义，不发明独立的失败协议。
- 失败只影响其下游；无关链路与已成功上游保持不变。
ODS 再次修复：受影响 SUCCESS 失效，历史日志保留
如果重做之后 ODS 又被修复了一次，已经重做成功的下游结果就不再代表最新输入。平台会重新根据血缘入队，把受波及的下游 SUCCESS 清空为 WAITING；未受波及的实例保持成功。
执行日志是排查恢复过程的唯一依据：每次停止、验证、重做、失败和失效都按当时的时分秒记录，历史记录只追加、不覆盖。日志里没有「第几轮」这样的编号——真实平台记录的是时间与事件，不是轮次。
- 再次修复 → 重新计算影响范围 → 受影响 SUCCESS 失效等待。
- 日志按时间追加，保留历史执行记录。
- 不引入轮次 / generation 字段；模拟器内部标识只用于演示计划隔离。
放在一起看
「依赖串行」与「全局并发数 1」不是一回事
本案例只建模依赖顺序，不对平台并发能力做假设。
受控链上上游先于下游
- 上游成功后下游才被调用，这是依赖语义。
- 同一受控链上的重做按顺序推进。
- 与无关链路可以在平台策略允许时并行。
平台级并发配置
- 把所有任务压成一条队列执行，性能与恢复时间都受影响。
- 不是本案例的假设，也不是通用的平台默认值。
- 实际并发、重试与命令规则以本地生产规则为准。