Apache DolphinScheduler 依赖节点执行状态异常问题分析

问题背景

在Apache DolphinScheduler工作流调度系统中，存在一个关于依赖节点状态判断的重要问题。当上游工作流被部分重新执行时，即使下游工作流只依赖上游的某个特定任务，且该任务之前已经成功执行过，下游工作流仍可能因依赖检查失败而无法正常执行。

问题现象

假设存在两个工作流A和B：

• 工作流A包含任务A-1、A-2和A-3
• 工作流B依赖工作流A中的任务A-3

当工作流A完整执行完成后，如果用户单独重新执行工作流A中的任务A-1（与工作流B无关的任务），而此时同一调度周期内的工作流B尚未执行，那么工作流B中的依赖节点将会失败，导致整个工作流B实例执行失败。

技术原因分析

当前系统的依赖检查机制存在以下设计特点：

1. 实例选择逻辑：系统会查找每个调度周期内endTime最新的工作流实例进行依赖检查。当用户单独重新执行某个任务时，系统会选择这个部分执行的工作流实例作为检查对象。

2. 状态绑定问题：依赖检查将任务实例状态与工作流实例状态紧密绑定。当检查的工作流实例中不包含下游依赖的任务时（如只执行了A-1而未执行A-3），系统会认为依赖条件不满足。

3. 重试机制影响：如果上游依赖任务设置了重试机制，当下游工作流在重试间隔期间执行依赖检查时，可能会因为上游任务处于失败状态而错误地判定依赖不满足。

影响范围

这个问题在以下场景中尤为突出：

1. 工作流迭代开发：在迁移或重构工作流时，开发人员需要频繁修改和部分重新执行任务。

2. 长周期工作流：上游工作流执行时间较长，下游工作流调度时间较晚，中间可能发生部分任务重新执行。

3. 重试场景：上游任务设置了重试机制，下游工作流可能在重试间隔期间执行依赖检查。

解决方案探讨

针对这一问题，社区提出了几种改进思路：

1. 解耦任务与工作流实例状态：不应将任务实例状态完全绑定到工作流实例状态，而应该独立检查每个依赖任务的历史执行状态。

2. 改进实例查询逻辑：在查询工作流实例时，应确保包含所有下游依赖的任务实例，而不仅仅是选择最新的工作流实例。

3. 重试场景优化：对于设置了重试机制的上游任务，下游依赖检查应等待所有重试完成后再做最终判断。

实现建议

从技术实现角度，建议关注以下关键点：

1. 修改DependentExecute类中的依赖检查逻辑，特别是dependResultByAllTaskOfProcessInstance方法。

2. 优化工作流实例查询SQL，确保查询结果包含所有必要的任务实例信息。

3. 考虑引入任务执行历史状态缓存机制，避免频繁查询数据库。

4. 对于重试场景，可以引入依赖检查的延迟机制或轮询机制。

总结

Apache DolphinScheduler中的这一依赖检查问题反映了工作流调度系统中任务状态管理的复杂性。理想的解决方案应该在保证数据一致性的前提下，提供更灵活的依赖检查机制，适应实际业务中常见的部分重新执行和重试场景。随着系统架构的演进，这一问题有望得到更完善的解决。