节点&任务状态优化

[ecoli666]

需求背景

任务执行时，用户希望任务发生状况 时，他能够清晰、及时的感知到。例如快速筛选有状况的任务、收到平台推送的通知等

因为理论上用户都是先关注到任务状态，当看到任务 发生状况 时，才有向下查找原因的诉求

而任务都是一个个节点组成的。所以节点的 任何状况 时，都应该体现在任务状态上，以便第一时间能让用户感知到。

现状

1. 任务进入审批和人工确认时，任务状态还是“执行中”。用户不进到任务内部，很难知道当前节点正 “等待处理” 。

2. 子流程暂停流转了，任务状态还是 “执行中”。实际此时任务已经卡住不能往下了。任务状态同样没有体现 “状况”

3. "等待处理"、暂停流转这类 “有状况的节点” 都会造成任务pending，此时还可以对任务发起 “暂停”

4. 节点失败时，没有细分（执行失败、超时、强制终止）

其它需要解决的点

1. 由于并行的存在，会存在多个状况节点，那么如何体现到任务状态上？

2. 当包含子流程时，任务就形成了多层嵌套 任务 -> 子流程节点 -> 子级节点。三个层级的状态如何确定？

状态优化

1. 当节点发生状况时，从下往上，根据节点的状态，确定父级的状态，逐级计算最终确定任务状态

2. 有存在多个 状况节点 时，按优先级决定父级状态

   **优先级：节点失败 > 节点等待处理 **

3. 节点失败增加细分原因

状态表：

4. 流程基础信息增加 “等待处理” 通知设置。

5. 强制终止、等待处理（原来的暂停） 两个针对节点的操作，引发的任务状态变更不触发任务通知，因为这两个属于人工介入引发的变更。

最终效果

1. 任务有节点 执行失败/超时/强制终止

2. 任务进入 审批/人工确认节点

3. 任务有子流程节点 等待处理

任务操作优化

1. 节点失败、节点等待处理 、节点暂停 都是不同形式的任务pending，这时候不应该再允许 “暂停” 任务

2. 任务的 “暂停”操作，发起“暂停”操作后，在画布上展示卡住的位置或卡住的节点

[normal-wls]

1. 对于优化1，本质上只是将失败状态延后暴露给用户。
   只要有一个节点失败，那么这个任务必然会失败，只是当时还有节点在执行中，目前的方案只是将这个最终状态提前暴露给用户。从实际场景触发，用户越早感知到有节点失败可以越早介入处理，节省任务的执行时间，这个收益应该比描述上的准确要更大。
2. 暂停信号需要进行级联，终止信号是否也需要，是否独立&非独立子任务都需要。

[EchoQT]

如果已有部分节点失败或暂停（或等待中）了，这些情况需要用户及时关注吧？包括如果有推送设置的话，这种情况也需要及时推送用户通知吧？
一律按进行中来考虑的话，虽然分类上更严谨了，但不符合实际需求。

另外，完成和失败两种任务状态的标准就是任务结束了，不需要按所有节点的状态情况来判断，任务引擎知道一个任务是否结束了。
那么，等待中或部分节点失败，但任务并未结束的情况，不符合上述标准，也不应纳入上述状态中。

再考虑一下吧。

[normal-wls]

1. 等待审批/确认的状态跟插件的逻辑强绑定，并非通用化节点状态，只能针对插件进行特殊处理。如果要做的话，需要列出对应的插件。同时需要考虑是否只支持内置插件，如果第三方插件开发者有类似需求，是否要进行支持。
2. 状态明细是否只针对本任务的节点进行展示，不进行下钻展示
3. 目前节点的失败原因无法进行区分，不同原因的失败都是将节点修改为失败状态，涉及定制化改造不建议，这块感觉意义不大，需确认是否一定要支持
4. 对于并行网关，如果一个是已暂停/废弃，一个是执行中，状态需要是什么。建议补充多分支情况下的状态表格
5. 子流程状态到父流程状态传递，可能会涉及多层流程状态传递，需要确定状态判定的优先级，如子流程失败，则父流程一定失败，即使当前还有执行中的节点等，建议补充表格展示

[ZhuoZhuoCrayon]

「定时」执行中的新状态是「等待处理」 - 等待处理不允许用户暂停，会不会导致「暂停不及时」

如果定时过程中可以暂停，那用户就可以在「消息展示」前，大概率暂停住任务

实现方案：

• 基于 /taskflow/api/status /apigw/sops/get_task_status/ 进行改造

• 兼容方案：感觉网关的获取状态不好动，可能其他系统有依赖，需要梳理

[ZhuoZhuoCrayon]

CheckList

• 遍历 PipelineTree，找到所有的审批、人工、节点 get_task_status_v2(gcloud/taskflow3/domains/dispatchers/task.py)
• 遍历状态树，自下往上确认状态 get_task_status_v2(gcloud/taskflow3/domains/dispatchers/task.py)
• 如果节点状态为 RUNNING 并且命中节点类型，修改节点及 root 的状态（优先级 FAILED > RUNNING）
• 任务记录页面改造（目前状态为懒加载，前端并发）

节点

• pause_node
• bk_approve

联调（一期）@ywywZhou

目前后台完成了「等待处理」部分的功能，需要前端配合改造的：

1. 任务状态展示支持以下类型：

等待审批 - PENDING_APPROVAL
等待确认 - PENDING_CONFIRMATION
等待处理 - PENDING_PROCESSING

2. 任务列表支持过滤「等待处理」，ask_instance_status=pending_processing

3. 通知方式增加（Update：10月10号）

数据结构（在原有基础上，增加 pending_processing）

{"success": [], "fail": [], "pending_processing": ["email"]}

[ecoli666]

状态表更新：