Camunda DMN引擎中FEEL表达式"in"与"satisfies"组合的回归问题分析

问题背景

在Camunda BPM平台的7.19.0到7.20.0版本升级过程中，用户报告了一个关于DMN决策表中FEEL表达式评估的回归问题。具体表现为当使用"every k in ? satisfies k.B in ["42"]"这类组合表达式时，评估结果出现了不一致的情况。

问题重现

通过用户提供的测试用例可以清晰地重现该问题。在7.19.0版本中，表达式"every k in ? satisfies k.B in ["42"]"对输入列表[{"B":"42"},{"B":"42"}]的评估结果为true，而在7.20.0版本中却返回了false。类似地，使用"count(?[item.B in ["42"]]) = count(?)"表达式也出现了相同的问题。

技术分析

深入分析后发现，这个问题实际上源于Camunda FEEL引擎的实现。当DMN引擎调用FEEL引擎评估表达式时，特定的表达式组合触发了评估逻辑的异常。值得注意的是：

1. 单独使用FEEL引擎测试相同表达式时，评估结果是正确的
2. 问题仅出现在通过DMN引擎调用FEEL引擎的场景中
3. 使用"list contains"作为替代方案可以暂时规避此问题

根本原因

经过进一步排查，发现这是由于FEEL引擎在处理嵌套表达式时的类型转换问题导致的。具体来说：

1. 当"in"操作符与"satisfies"组合使用时
2. 在特定上下文环境下，类型推断出现了偏差
3. 导致集合成员检查的逻辑未能正确执行

解决方案

Camunda团队已经在新版本的FEEL引擎中修复了这个问题：

1. FEEL Engine 1.17.5版本完全解决了此问题
2. 对于需要保持稳定的环境，1.16.3版本也包含了修复
3. Camunda 7.21.0版本将默认集成修复后的FEEL引擎

最佳实践建议

对于使用Camunda DMN引擎的开发人员，建议：

1. 检查项目中是否使用了类似的复杂FEEL表达式组合
2. 考虑升级到包含修复的FEEL引擎版本
3. 对于暂时无法升级的环境，可以使用"list contains"作为临时替代方案
4. 编写单元测试验证关键业务规则的评估结果

总结

这个问题展示了业务流程自动化中规则引擎评估的复杂性。通过Camunda团队和社区的协作，及时定位并修复了底层引擎的问题，确保了业务规则评估的准确性。这也提醒我们在进行平台升级时需要充分测试关键业务规则的评估逻辑。