💡  本系列文章是 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 的生成，下次接着讲，希望可以帮到你。

本文由 白鲸开源科技 提供发布支持！