Dependency node new feature: Wait for the dependency to start Current Features
When the current dependent node executes, if it is found that the dependent task node has not started to execute, the node will be directly judged as a failure. New Feature Target When the execution reaches the dependent node, if there is no ready in the list of dependent task nodes, the node will wait for a while. If the dependent task nodes are started within the waiting time, execution continues; otherwise, the node fails to execute. Plan Plan A By using the existing timeout judgment mechanism, waiting for the dependent node to start and waiting for the dependent node to complete is regarded as an equivalent state, so as to achieve the goal. In the original mechanism, if the timeout attribute is not set, then a dependent task node will wait indefinitely until it is completed when the task node has been started; if the timeout attribute is set, then the waiting time is limited . If this scheme is used, the new dependent node will exhibit the following behavior: If the timeout attribute is not set: If the dependent node finds that the dependent task node has not started, the dependent node will wait indefinitely for it to start (the original one failed directly); The behavior of the dependent task node that has been started is the same as before. If the timeout attribute is set: If the dependent node finds that the dependent task node has not started, the dependent node will wait for it to start for a period of time, and if the wait times out, it will be treated the same as the dependent task running timeout; The behavior of the dependent task node that has been started is the same as before. Program advantages: Simple implementation, less code changes, and even the front end can be left unchanged. Disadvantages: Cannot distinguish between two concepts of waiting to start and waiting to complete (question: is it important for users to distinguish these two concepts?) Plan B A special delay-waiting attribute is added for dependent nodes. Although this attribute is called "delay-waiting", it is closer to the "timeout setting" at the conceptual level. Program advantages: Simpler, less code changes; Ability to set supermarket time separately for waiting for dependency start and waiting for completion. Disadvantages: The two attributes are similar in concept and appear redundant in design. At last For the above problem, the dependent task node is not started, is executing but timed out, and failed to run. I think they are all the reasons for the dependent node execution failure, and there is no obvious difference between them. I personally prefer Plan A. 依赖节点新特性：延时等待 目前特点 当前依赖节点执行时，若发现被依赖任务节点尚未开始执行，该节点就会被直接判为失败。 新特性目标效果 当执行到依赖节点时，若被依赖的任务节点列表中存在没有就绪的，那么该节点会等待一段时间。若果等待时间内被依赖任务节点都启动了，就继续执行；否则该节点执行失败。 实现方案 方案A 利用已有的超时判断机制，将等待被依赖节点启动和等待被依赖节点完成视为等价的状态，从而达到目标。在原有的机制中，如果没有设置超时属性，那么一个被依赖任务节点在已经启动的情况下，依赖节点会无限期地等待直到它完成；如果设置了超时属性，那么这个等待时间就有了限制。 如果使用这个方案，那么新的依赖节点将会表现出以下行为： 如果没有设置超时属性： 如果依赖节点发现被依赖任务节点没有启动，依赖节点会无限期地等待它启动（原来的是直接失败）； 对于已经启动的被依赖任务节点，行为与以往相同。 如果设置了超时属性： 如果依赖节点发现被依赖任务节点没有启动，依赖节点会在一段时间内地等待它启动，如果等待超时了，将与被依赖任务运行超时同等对待； 对于已经启动的被依赖任务节点，行为与以往相同。 方案优点： 实现简单，代码改动少，前端甚至可以不改。 缺点： 前端同学可能会失业； 不能够区分等待启动和等待完成两个概念（疑问：对于用户来说区分这两个概念重要吗？） 方案B 为依赖节点专门新增一个延时等待的属性，这个属性虽然叫做“延时等待”，但它在概念层面上与“超时设置”更加贴近。 方案优点： 较为简单，代码改动少； 能够单独为等待依赖启动和等待依赖完成设置超市时间。 缺点： 两个属性概念上雷同，显得设计冗余。 最后 对于上面的问题，我认为被依赖任务节点未启动、正在执行但超时、运行失败都是依赖节点执行失败的原因，它们并没有明显的区别。 我个人倾向于方案A。
