fix(fel): 修复 Action 执行时的偶发报错

[CodeCasterX]

问题摘要 / Issue Summary

执行 Github Action 偶现报错，重试后成功

版本信息 / Version Information

v3.5.0-M6

浏览器 / Browser

No response

操作系统 / Operating System

None

发生了什么？/ What happened?

有 FEL 单测在 Action 过程中报错，重试后成功

期望的行为 / Expected Behavior

不应该出现偶现的报错

重现步骤 / Steps to Reproduce

可能无法重现，需要通过上述的截图日志进行代码分析

相关日志 / Relevant Logs

额外信息 / Additional Context

No response

确认事项 / Confirmations

• 我已经搜索了现有的issues，确认这不是重复问题
  I have searched existing issues and confirmed this is not a duplicate

• 我已经阅读了项目文档和 FAQ
  I have read the project documentation and FAQ

• 我提供的信息准确完整
  The information I provided is accurate and complete

• 我愿意协助测试问题修复 (可选)
  I'm willing to help test the bug fix (optional)

[CodeCasterX]

本地执行单测也出现了偶现报错：

[CodeCasterX]

问题分析

经过代码分析，这是一个 并发竞态条件（Race Condition） 问题。

根本原因

问题出现在 runnableParallel 的 fork/join 操作中：

错误堆栈：

java.lang.NullPointerException: Cannot read field "values" because "other" is null
	at modelengine.fel.core.util.Tip.merge(Tip.java:121)
	at modelengine.fel.engine.activities.AiStart.lambda$runnableParallel$17(AiStart.java:596)

触发流程：

1. 在 Fork.java:96-104 的 join 实现中，当并行分支还未全部完成时，会返回 null：

if (acc.second() == forkNumber.get()) {
    accs.remove(key);
    return acc.first();
} else {
    return null;  // ← 问题所在
}

2. 这个 null 在某些竞态情况下会被传递到 AiStart.java:596 的 reduce 函数中：

aiFork.join(Tip::new, (acc, data) -> {
    acc.merge(data);  // ← data 可能为 null
    return acc;
});

3. Tip.merge(null) 尝试访问 null.values，导致 NPE

为什么是偶现：只有在特定的线程调度时序下，中间的 null 返回值才会被错误传递给 reduce 函数。

---

解决方案

方案 1：在 Tip.merge 中添加空值检查（防御性编程）

修改 framework/fel/java/fel-core/src/main/java/modelengine/fel/core/util/Tip.java:120-122：

public Tip merge(Tip other) {
    if (other == null) {
        return this;
    }
    return this.addAll(other.values);
}

方案 2：在 AiStart.runnableParallel 中添加保护

修改 framework/fel/java/fel-flow/src/main/java/modelengine/fel/engine/activities/AiStart.java:595-598：

AiState<Tip, D, Tip, RF, F> state = aiFork.join(Tip::new, (acc, data) -> {
    if (data != null) {
        acc.merge(data);
    }
    return acc;
});

方案 3：修复 Fork.join 的底层逻辑（根本修复）

需要审查 framework/waterflow/java/waterflow-core/src/main/java/modelengine/fit/waterflow/domain/states/Fork.java 中的 join 实现，确保中间状态的 null 不会被传递给 reduce 函数。

---

推荐方案

建议采用方案 1 + 方案 2 的组合：

• 方案 1 提供防御性保护，避免类似问题扩散
• 方案 2 明确处理业务逻辑中的 null 情况
• 方案 3 作为长期优化项，需要更深入的设计审查

@loveTsong 请帮忙确认一下这个分析是否正确，以及倾向于哪种修复方案？

[loveTsong]

当前报错位置在join提供的处理器中，这里的join操作是将提供的所有patterns对应的fork分支的结果进行聚合。

1. 测试用例中提供了两个pattern，返回的结果为Tip对象。
2. 在runnableParallel中将上述两个pattern分别fork分支执行。
3. 最后将fork的两个分支进行join操作，join中会把两个分支的结果进行聚合。这里会将两个分支的结果全部聚合完，然后聚合后的结果继续想后续节点流动。

[CodeCasterX]

深入分析更新

感谢 @loveTsong 的说明！基于您的反馈，我重新分析了问题的根本原因。

问题本质

根据代码追踪，完整的执行流程是：

1. Fork.java:96-104 中的 wrapper 处理器在收集分支结果时：

   • 当 acc.second() == forkNumber.get() 时，说明所有分支都完成，返回聚合结果
   • 否则返回 null，表示"中间状态，还在等待其他分支"

2. JoinNode.java:60-62 应该通过 postFilter 过滤掉未收集齐的数据

3. 问题发生点：在某些并发时序下，wrapper.process() 返回的中间状态 null 没有被正确过滤，而是被传递到了用户提供的 reduce 函数，导致 Tip.merge(null) 触发 NPE

疑问点

想向 @loveTsong 确认：

1. 中间 null 为什么会泄漏到 reduce 函数？ 按设计，JoinNode 的 postFilter 应该只在收集齐所有分支后才处理数据，是否存在某些边界条件？

2. Fork.java:107-109 的实现是否符合预期？ 每个分支都 subscribe 到同一个 JoinNode，postFilter 是否在所有并发场景下都能正确工作？

修复方案建议

基于完整分析，我建议采用双重防护策略，快速解决当前偶现问题，然后作为长期优化项审查底层架构。

@loveTsong 您觉得这个分析是否正确？倾向于哪种修复方案？

[CodeCasterX]

具体修复方案

方案 1：在 Tip.merge 中添加空值检查（防御性编程）

修改 framework/fel/java/fel-core/src/main/java/modelengine/fel/core/util/Tip.java:120-122：

public Tip merge(Tip other) {
    if (other == null) {
        return this;  // 防御性处理中间状态的 null
    }
    return this.addAll(other.values);
}

优点：最小化风险，避免类似问题扩散到其他使用 Tip.merge 的地方

方案 2：在 AiStart.runnableParallel 中添加保护

修改 framework/fel/java/fel-flow/src/main/java/modelengine/fel/engine/activities/AiStart.java:595-598：

AiState<Tip, D, Tip, RF, F> state = aiFork.join(Tip::new, (acc, data) -> {
    if (data != null) {  // 明确过滤中间状态的 null
        acc.merge(data);
    }
    return acc;
});

优点：明确处理业务逻辑中的 null 情况，符合防御性编程原则

方案 3（长期优化）：审查 Fork/Join 底层逻辑

深入审查：

• JoinNode 的 postFilter 在高并发下的行为
• wrapper.process() 返回 null 的语义是否被正确处理
• 是否需要引入 Optional<R> 或其他机制来区分"中间状态"和"有效的 null 值"

---

推荐方案：先实施方案 1 + 方案 2 快速修复，然后方案 3 作为长期优化项。