目测是因为 5 号这个节点最先失败，当工作流中任意一个节点失败且不可跳过的时候，整个工作流就会被 “停止” （不会再运行新的节点）

@Echo009 我的需求其实是运行一个树形结构的任务，父结点的失败只影响他的直接子结点。
也就是说，上图中的5号结点的失败，不要影响8号结点（因为6号结点运行是正确的）。

这样的需求，能在一个工作流中实现吗？ 或者有其他推荐的方式吗？

@Echo009 另外一个问题，工作流重试的逻辑是怎样的？ 如果是从头运行，那下面这个情况怎么理解？

@Echo009 我的需求其实是运行一个树形结构的任务，父结点的失败只影响他的直接子结点。 也就是说，上图中的5号结点的失败，不要影响8号结点（因为6号结点运行是正确的）。

这样的需求，能在一个工作流中实现吗？ 或者有其他推荐的方式吗？

如果是 v4.1.0 的版本，可以用嵌套工作流实现你想要的效果，将联系紧密的分支放到子工作流里，父工作流在失败的时候不会终止正在运行的子工作流。

@Echo009 另外一个问题，工作流重试的逻辑是怎样的？ 如果是从头运行，那下面这个情况怎么理解？

原地重试的时候会启动所有当前已就绪的节点（其所依赖的上游节点都处于 完成/失败可跳过/未启用 的状态）

在你的这个案例里边就是节点 5,8,9 会同时启动

目测是因为 5 号这个节点最先失败，当工作流中任意一个节点失败且不可跳过的时候，整个工作流就会被 “停止” （不会再运行新的节点）

感谢。 上面说“整个工作流会被停止”， 那有没有以下这种可能呢？
极端情况下，假设5很快运行结束，并且失败了， 4，6，7还没来得及被调度，那4，6，7是不是就不运行了？

不会，在这个案例下，节点 4/5/6/7 在 DAG 里属于同一层级（依赖的上游节点都是同一个），所以它们会被“同时”触发，节点 4/5/6/7 一定是会被执行的

如果是 v4.1.0 的版本，可以用嵌套工作流实现你想要的效果，将联系紧密的分支放到子工作流里，父工作流在失败的时候不会终止正在运行的子工作流。

@Echo009 感谢你的回复。 但是我没有想明白。以下面的图为例，白色背景的节点代表运行正确的，红色背景代表运行失败的。怎么用嵌套工作流解决呢？

从普通用户的角度，我觉得现在的实现理解起来不太直观，比如下图，第一感觉节点8和9应该是可以运行的。
这个地方是有哪些权衡或者考量呢？ 或者是为了和竞品对齐？

从普通用户的角度，我觉得现在的实现理解起来不太直观，比如下图，第一感觉节点8和9应该是可以运行的。 这个地方是有哪些权衡或者考量呢？ 或者是为了和竞品对齐？

当前的设计思想遵循 “fail-fast ”原则，将工作流视为一个整体，如果单个任务失败，会打断整个工作流。
并不是为了跟竞品对齐，不过貌似 DolphinScheduler 里也是这么个处理逻辑。
🤔，你说的也有道理，这样不够直观，后续会考虑要不要调整这里的处理逻辑

从普通用户的角度，我觉得现在的实现理解起来不太直观，比如下图，第一感觉节点8和9应该是可以运行的。 这个地方是有哪些权衡或者考量呢？ 或者是为了和竞品对齐？

当前的设计思想遵循 “fail-fast ”原则，将工作流视为一个整体，如果单个任务失败，会打断整个工作流。 并不是为了跟竞品对齐，不过貌似 DolphinScheduler 里也是这么个处理逻辑。 🤔，你说的也有道理，这样不够直观，后续会考虑要不要调整这里的处理逻辑

好的， 多谢。 这块儿的处理逻辑，可以提PR吗？

从普通用户的角度，我觉得现在的实现理解起来不太直观，比如下图，第一感觉节点8和9应该是可以运行的。 这个地方是有哪些权衡或者考量呢？ 或者是为了和竞品对齐？

当前的设计思想遵循 “fail-fast ”原则，将工作流视为一个整体，如果单个任务失败，会打断整个工作流。 并不是为了跟竞品对齐，不过貌似 DolphinScheduler 里也是这么个处理逻辑。 🤔，你说的也有道理，这样不够直观，后续会考虑要不要调整这里的处理逻辑

好的， 多谢。 这块儿的处理逻辑，可以提PR吗？

非常欢迎哈，不过建议先提 issue ，再具体描述一下需求背景，以及你的期望啥的。

这个毕竟会影响到现有的工作流处理，需要先内部评估一下 ~