IIB消息流报BIP2652：出队失败消息传播至故障终端问题咨询

BIP2652本身不是根因错误，它是MQ输入节点判定消息处理失败、即将把消息路由到Failure终端的提示性日志，真正的触发原因需要按以下步骤排查：

• 先定位根因日志
  不要仅围绕BIP2652排查，去集成节点对应日志目录（Linux/Unix路径为$MQSI_WORKDIR/components/<节点名>/log，Windows可通过事件查看器关联定位），找到这条BIP2652打印时间点前10秒内所有严重级别≥2的错误条目，真正触发失败的根因（JSON解析失败、ESQL执行错误、HTTPS连接异常、MQ参数不匹配等）一定早于BIP2652打印。
• 针对当前流结构重点排查高频触发场景
  • MQ输入节点基础配置校验
    检查节点Backout threshold（回退阈值）参数，如果配置为1，消息第一次处理抛出异常就会直接触发Failure终端路由。同时确认Parse timing参数：如果设置为Immediate，消息从队列取出瞬间就会执行JSON解析，只要消息体不合法、CCSID/编码配置和实际消息不匹配，解析失败会直接在MQ Input节点内部抛出，根本不会传递到下游Compute、HTTPS节点，错误直接从Failure终端输出。
  • JSON解析类问题排查
    你配置的消息域为JSON，直接从输入队列取触发报错的原始未消费消息，在流测试器中导入验证是否能被JSON解析器正常解析，重点排查非法JSON结构、不匹配CCSID的特殊字符、消息头Format字段和实际消息体不匹配的问题。这类发生在MQ Input节点内部的解析错误，不会路由到Out终端，也不会触发Catch终端逻辑。
  • 异常路由逻辑校验
    注意Catch终端的触发边界：只有消息从MQ Input节点Out终端流出后，下游Compute、HTTPS Request节点抛出的未捕获异常才会走到Catch终端；如果异常发生在MQ Input节点自身取消息、解析、参数校验阶段，只会走Failure终端，不会进入Catch逻辑。你调试时看到错误从Failure终端抛出，基本可以优先排查节点内部处理阶段的问题，不用先查下游节点逻辑。
  • Backout队列隐性配置校验
    除了确认队列存在，还要额外检查两点：一是运行集成节点的服务账号是否拥有backout队列的写入权限，二是MQ Input节点配置的Backout requeue name是否准确填写backout队列全名（注意大小写、队列管理器归属，不要配置成队列别名），如果回退阶段找不到可写入的backout目标，会循环触发BIP2652报错。
• 快速定位根因的方法
  临时在MQ Input节点的Failure终端接入Trace节点，Trace模式配置为记录完整${ExceptionList}内容并输出到本地文件，ExceptionList会保存从最初抛出的根异常到BIP2652的完整错误栈，能直接定位报错的具体组件和错误码，不需要逐行翻日志猜测原因。

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