ExecGo 的调度器对失败/重试/跳过的语义是确定的。上层编排层需要理解并正确处理：

• 某个任务最终 failed 后，下游依赖它的任务会被标记为 skipped
• skipped 会级联跳过所有下游孙节点（dependency 失败导致级联）
• retry 只影响“该任务自己的执行重试次数”，不影响依赖图结构

1. 重试与超时（每次尝试）

• task.retry 表示失败后尝试的次数
• 实际尝试次数 = task.retry + 1（首次尝试也算一次执行）
• 每次尝试都会创建独立的上下文；当 task.timeout > 0 时，每次尝试受超时限制

上层编排层应把 retry/timeout 当作“任务级策略”，而不是“工作流级策略”。

2. 下游为何会变成 skipped

当某个任务在所有重试后仍失败：

• 调度器把它标记为 failed
• 然后把所有直接下游任务标记为 skipped
• skipped 会继续级联到更深层下游

因此你在编排层做决策时，至少需要区分：

• failed：该节点自身执行问题（最终失败）
• skipped：上游依赖失败导致的不执行（通常不需要重复“解释失败原因”）

3. 轮询时的状态判定建议

当你轮询到某个任务状态：

• success：可以继续推进（但注意“参数产物”仍需你在编排层处理）
• failed：通常需要终止或切换工作流分支（按你的业务策略）
• skipped：说明失败来自上游依赖；你的逻辑应从上游失败定位，而非从被跳过节点本身

4. 结合 Task.result / Task.error 的处理方式

ExecGo 会把：

• 成功结果写入 Task.result（JSON raw 字段）
• 失败原因写入 Task.error（字符串）

上层编排层通常会：

• 对成功任务：解析 result 并用于后续 params 注入
• 对失败任务：记录 error 以便可观测与告警