Apache DolphinScheduler 依赖任务执行状态检查机制分析与优化建议

问题背景

在Apache DolphinScheduler工作流调度系统中，存在一个关于任务依赖关系的执行状态检查机制问题。当上游工作流中的某个任务被单独重新执行时，可能会导致依赖该工作流中其他任务的下游工作流执行失败，即使被依赖的任务之前已经成功执行过。

问题现象

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

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

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

技术原理分析

当前系统的实现逻辑是：在检查依赖关系时，会查找每个周期内结束时间最晚的工作流实例。当单独重新执行任务A-1时，系统会找到包含这个重新执行任务的工作流A实例，但这个实例中并不包含任务A-3（因为只重新执行了A-1）。由于工作流A实例处于完成状态，而找不到被依赖的任务A-3实例，系统会将依赖节点标记为失败，进而导致工作流B失败。

问题本质

这个问题的核心在于当前的任务实例状态检查机制与工作流实例状态过度绑定。系统设计初衷是为了方便选择"ALL"依赖选项（即依赖整个工作流的所有任务），无需检查上游工作流中每个任务的状态，而是直接检查整个上游工作流的状态。然而，在实际工作中，工作流的修改和部分任务的重新执行是常见需求，这种设计会导致不必要的下游工作流失败。

典型场景分析

1. 部分任务重新执行场景：

   • 上游工作流在凌晨1点调度执行
   • 下游工作流在上午10点调度执行
   • 在上午7点重新执行上游工作流中与下游依赖无关的某个任务
   • 下游工作流在10点执行时会失败

2. 任务重试场景：

   • 设置任务A-3的失败重试时间为5分钟
   • 工作流A在7:00因A-3失败而失败
   • 工作流B在7:03因A-3状态为失败而失败
   • A-3在7:05重试并成功
   • 最终结果：工作流A状态为成功，工作流B状态为失败

优化建议

1. 解耦任务实例状态与工作流实例状态：

   • 修改依赖检查逻辑，使任务实例状态不再与工作流实例状态强绑定
   • 对于依赖特定任务的情况，应检查该任务的历史执行状态，而不仅限于最新工作流实例中的状态

2. 重试机制优化：

   • 对于设置了重试策略的被依赖任务，下游任务应等待直到上游任务完成所有重试尝试
   • 只有当上游被依赖任务最终失败时，才标记下游依赖节点为失败

3. 依赖检查逻辑改进：

   • 在查询最新工作流实例时，确保包含被依赖的任务实例
   • 对于"ALL"依赖选项，保持现有逻辑
   • 对于特定任务依赖，采用不同的检查策略

实现路径

可以从以下关键代码入手进行优化：

1. DependentExecute#calculateResultForTasks方法
2. DependentExecute#getDependTaskResult方法
3. DependentExecute#dependResultByAllTaskOfProcessInstance方法

总结

Apache DolphinScheduler当前的依赖任务状态检查机制在实际使用中存在局限性，特别是在部分任务重新执行和任务重试场景下。通过解耦任务实例状态与工作流实例状态的绑定关系，并优化依赖检查逻辑，可以显著提高系统的灵活性和实用性。建议在后续版本中针对这一问题进行优化改进，以更好地满足实际业务场景需求。