一个任务失败，后面的任务会怎样？
注入一次 DWD 故障，观察失败如何影响下游，再执行 Retry 恢复同一条链。
DWD 失败以后，DWS 为什么没有开始？
一个任务失败，后面的任务会怎样？
同一条存款余额 DAG 中，DWD 第一次执行遇到临时数据库连接失败。看清 DWD、DWS、ADS 的状态变化，再用下一次 Attempt 让链路继续。
DWD 失败时，DWS 应该继续算、等待，还是报告成功？
核心概念
失败传播（Failure Propagation）
当上游任务没有产出可用结果时，依赖它的下游任务不能继续使用这次运行的数据。下游应保持等待或被阻断，直到上游 Retry 或人工恢复成功。
一次临时失败会留下什么证据？
DWD Attempt 1 在 02:02 开始，经过一次处理后因临时数据库连接失败结束。此时 DWD 进入 Retry；DWS 没有拿到成功的明细结果，所以保持等待，ADS 也不能发布。
如果重试耗尽，DWD 才会进入失败终态，DWS 和 ADS 会被阻断。状态的变化要沿依赖关系解释，不能只看某个节点的颜色。
- 运行中：任务已经开始执行。
- 成功：这次任务产出可供下游使用的结果。
- 失败：这次任务没有完成，需要 Retry 或人工处理。
- 等待：任务尚未具备继续运行的条件，不等于执行失败。
故障注入实验 · 状态沿依赖传播
让 DWD 失败一次，再观察下游如何恢复
选择“失败后自动重试”或“重试耗尽”，逐步推进同一业务日期的运行。重点观察 DWS / ADS 为什么等待，以及 Attempt 2 何时获得运行资格。
正在加载交互实验…
Retry 是一次新的尝试，不是新的业务日期
Retry 仍然处理 `snapshot_date = 2026-09-30`，只是为 DWD 增加 Attempt 2。输入、业务日期和目标分区没有因为失败而换掉；成功后，DWS 才能沿原来的 DAG 继续。
当失败确实不可自动恢复时，可以暂停下游并留下失败记录。人工检查后再恢复任务，恢复动作也必须保留在运行证据里。
- DWD Retry 时，DWS / ADS 等待上游结果。
- DWD 最终失败时，下游被阻断，不应误报 success。
- Recovery 后增加新的 Attempt，成功才重新放行依赖。