Camunda消息启动子流程遇异常重复执行3次问题排查

我来帮你捋清楚这个Camunda流程异常处理的问题，结合你的场景来看，核心问题是DMTTst抛出的Unknown property used in expression: ${TstRunX}错误，虽然被SubTst节点的捕获逻辑接住了，但流程没按预期执行SubOut1→SubOut2→SubOut3，反而反复回到SubParse节点重试3次后触发事务回滚。下面是具体的分析和解决思路：

问题根源分析 #

1. 默认重试机制触发：Camunda的服务任务（Service Task）如果抛出异常，默认会自动重试3次——这正好和你说的重复3次的现象吻合。哪怕你用边界错误事件捕获了异常，默认的重试机制还是会生效，导致流程回退到SubParse节点重新执行SubTst。
2. 异常捕获范围或配置问题：边界错误事件的关联逻辑可能没做对，比如没有精准匹配DMTTst抛出的异常类型/代码，或者捕获范围覆盖了不该覆盖的节点，导致流程走向异常。
3. 事务边界冲突：如果SubParse节点和后续的SubOut系列节点在同一个事务里，异常会触发整个事务回滚，流程状态直接回退到SubParse节点，而不是继续执行后续节点。

针对性解决方案 #

1. 关闭服务任务的自动重试 #

这是解决流程反复回退的关键一步，你可以通过两种方式实现：

• BPMN模型配置：给SubTst服务任务添加扩展属性camunda:retries="0"，直接在模型层面禁用重试。
• 代码层面设置：在启动DMTSub流程时，给SubTst节点设置重试变量，或者在服务任务的执行逻辑里手动设置：

// 启动DMTSub时指定重试参数
ProcessInstance subInstance = runtimeService.createProcessInstanceByMessage("你的消息名称")
  .setVariable("subTstRetries", 0)
  .execute();

// 或者在服务任务执行代码中设置
runtimeService.setVariable(execution.getId(), "camunda:retries", 0);

2. 修正异常捕获逻辑 #

• 确保边界错误事件是直接附加在SubTst节点上，而不是附加在父容器（比如子流程）上。如果DMTTst抛出的是自定义错误，要在边界错误事件中指定对应的错误代码；如果是Camunda内置的表达式错误，可以用不指定错误代码的通用捕获。
• 如果你用CallActivity调用DMTTst，要确保子流程DMTTst是通过错误结束事件抛出异常，而不是直接结束，这样父流程的边界错误事件才能正确捕获。

3. 调整事务边界避免回滚影响 #

把SubParse节点和后续的SubOut系列节点拆分成独立事务，这样即使SubTst抛出异常，也只会回滚SubParse所在的事务，后续节点可以正常执行：

• 在SubParse节点之后添加一个中间消息事件，让SubParse执行完后发送消息触发后续节点，实现事务拆分。
• 给SubOut1、SubOut2、SubOut3节点设置camunda:asyncBefore="true"，让这些节点在独立的事务中运行，不受前面异常回滚的影响。

4. 修复表达式错误的根源 #

先解决Unknown property used in expression: ${TstRunX}这个基础错误，避免异常触发：

• 检查从DMTSub调用DMTTst时，是否正确传递了TstRunX变量；
• 如果TstRunX是DMTTst内部生成的，确认是否在引用它之前已经完成初始化；
• 可以在DMTTst的起始节点加一个脚本任务，提前初始化TstRunX变量，避免表达式报错。

验证步骤 #

1. 先修复TstRunX变量的问题，测试流程是否能正常执行；
2. 如果需要保留异常场景，关闭SubTst的自动重试，确认异常捕获后流程是否按预期执行SubOut2/SubOut3；
3. 调整事务边界，测试异常后的流程执行路径是否符合预期。

内容的提问来源于stack exchange，提问作者namalfernandolk