💡 本系列文章是 DolphinScheduler 由浅入深的教程，涵盖搭建、二开迭代、核心原理解读、运维和管理等一系列内容。适用于想对 DolphinScheduler了解或想要加深理解的读者。
祝开卷有益。
本系列教程基于 DolphinScheduler 2.0.5 做的优化。（稳定版推荐使用3.1.9）
上篇回顾：海豚调度调优 | 正在运行的工作流(DAG)如何重新拉起失败的任务(Task)
最近调度稳定运行一段时间了，有时间分享一下我们在使用海豚调度过程中遇到的问题和使用经验，希望可以帮到大家。
今天分享的是任务被禁用出现的 Bug，包含两个相关联的问题。
已有的功能：在一个 DAG(工作流)中，存在节点被禁用的情况，表示该节点不会执行，执行到这个节点的时候，可以跳过这个节点继续执行下游节点。
问题1[1]：在 Version 2.0.1 中，存在一个 BUG，如下图所示，有 6 个节点，其中 test1_stop 和 test2_stop 节点是被禁用的。
从上图可以看出，test3 依赖 test1_stop 和 test2_stop。但是执行的时候，发现 test2 节点还在运行呢，test3 就已经执行了，并没有等待所有上游节点运行结束。
上述问题如何解决呢？
新增一个递归向上查找间接依赖的方法(如果是上游节点被禁用了，继续向上查找)
新增 setIndirectDepList 方法，如果该节点的上游被禁用了，则继续寻找上游。最终把所有的上游加到 indirectDepCodeList 这里。
/**
* This function is specially used to handle the dependency situation where the parent node is a prohibited node.
* When the parent node is a forbidden node, the dependency relationship should continue to be traced
*
* @param taskCode taskCode
* @param indirectDepCodeList All indirectly dependent nodes
*/
private void setIndirectDepList(String taskCode, List<String> indirectDepCodeList) {
TaskNode taskNode = dag.getNode(taskCode);
List<String> depCodeList = taskNode.getDepList();
for (String depsNode : depCodeList) {
if (forbiddenTaskMap.containsKey(depsNode)) {
setIndirectDepList(depsNode, indirectDepCodeList);
} else {
indirectDepCodeList.add(depsNode);
}
}
}
在 isTaskDepsComplete 方法中，引用这个 list ，遍历。
好的，问题1[1]到这里就结束了，修复之后，test3 的直接上游节点 test2_stop 被禁用时，会继续往上找到 test2, 如果 test2 还在运行，test3 不会立刻运行。
*负杂的系统，随着不断迭代，总会伴随着小"惊喜"。继续往下看 *
上述新增的逻辑，带来了问题2[2]，请看下图：运行test_del_node 节点，选择向后执行，按照正常的逻辑，会运行 test_del_node 和 test_del_node_36j 这两个节点。但是 test_del_node_36j 一直不执行。
查看 Master 日志发现，在提交 test_del_node_36j 这个节点的时候，出现了submit standby task error这个错误，拿到本地 debug 之后，发现在 setIndirectDepList 中出现了 NPE。最后定位到下面两行代码：
TaskNode taskNode = dag.getNode(taskCode);
List<String> depCodeList = taskNode.getDepList();
通过分析，最后发现是因为test_del_node_36j的节点的直接上游节点被禁用了，按照 setIndirectDepList 里面的逻辑，存在被禁用的节点，是会继续往上找的，找到间接依赖。
dag 在工作流启动的时候，根据 startNode 生成了关系图(dag)，dag 里面只有两个节点: test_del_node 和 test_del_node_36j 。此时递归查找test_del_node_36j 的上游节点的上游节点的时候，报了 NEP。
处理方式也比较简单，加一个 null 的判断。
这样，问题2[2]就解决了。
总结
-
问题1 在 2.0.3-release 中得到修复。
-
问题2 在 3.0.5-release 中得到修复。
如果不想升级的小伙伴，可以自行根据自己的版本，进行修改。
需要注意的是：
-
2.x 版本，对应的代码文件是 WorkflowExecuteThread.java
-
3.x 版本，对应的代码文件是 WorkflowExecuteRunnable.java
以上就是任务被禁用出现的Bug关联的两个问题的分享，如果有任何疑问，都可以与我交流，同样社区也推荐大家使用3.1.9版本，这是相对比较稳定的版本，上文中，还提到了 dag 的生成，下次接着讲，希望可以帮到你。
本文由 白鲸开源科技 提供发布支持！