对于前置节点放行(skip或success)，其中只要有一个success，其它为skip ,本节点应该为success

[Andioruser]

这是我贴出的实现方法,需要将原本的DoPrecheck的地方换成ShouldSkip，内部逻辑是先做DoPrecheck，如果阻塞，直接阻塞【状态在函数内部被更新为block】，如果skip直接返回，状态也被函数自动更新，再进行放行的前置节点检查（success或skip）,其中只要有success，那么本节点也应该success。
调用shouldSkip的时候，先判断taskstatus有没有因为调用了doprecheck被设置成了skip或者success，然后再根据ShouldSkip的返回值来判断，yes就是skip,no就是success。

func (t *TaskInstance) ShouldSkip(dagIns *DagInstance) bool {
    if t.PreChecks != nil {
        if ok, _ := t.DoPreCheck(dagIns); ok {
            return t.Status == TaskInstanceStatusSkipped
        }
    }

    // 自动判断前置 skip 传播
    allSkipped := true
    for _, depID := range t.DependOn {
        dep := dagIns.GetTaskInstanceByID(depID)
        if dep.Status != TaskInstanceStatusSkipped {
            allSkipped = false
            break
        }
    }

    return allSkipped
}

[Andioruser]

如果大佬看到了，可以商量一下是否合理，代码部分我来写，麻烦您帮忙review一下，感谢

[ShiningRush]

hi Andioruser, 感谢你的提案，但是这里存在几个问题：

1. 在 DoPreCheck 之后没有检查error，这个逻辑和原来的变化很大
2. 在PreCheck有条件生效后，返回的布尔值是 t.Status == TaskInstanceStatusSkipped，这会导致 block 等状态的激活被忽略
3. ShouldSkip函数看起来相比较于 DoPreCheck 排除我已经指出的 1,2 两点外，还有个不同之处是在PreCheck没有被激活时，会检测所有前置节点是否全为skip，如果全为Skip，那么它也应该进入skip。这个逻辑不是很合理，因为在工作流引擎角度来说，后序节点是否跳过不取决于前序节点，所以如果你需要跳过，建议你在自己的Action里面去检查 ShareData 中是否有对应的Flag，会更合适些