Spring Integration升级后HTTP网关响应丢失，错返其他Flow输出

1. HTTP入站网关响应未返回、第二个Flow输出被返回的原因 #

核心问题：临时回复通道的错误传播与版本行为变更 #

• 临时回复通道的不当传播：HTTP入站网关会为每个请求创建专属的TemporaryReplyChannel，并将其存入消息头的replyChannel字段。如果第二个Flow的消息继承了这个replyChannel头（比如消息触发时未做头隔离），当第二个Flow处理产生输出时，会自动将结果发送到该临时通道——而HTTP网关正等待此通道的响应，因此错误接收了第二个Flow的输出。
• Spring Integration 6.x的行为变更：
  • 6.x版本强化了消息头的默认传播策略，相比5.5.x，replyChannel这类请求级头会被默认保留并传递到后续流程。
  • publishSubscribeChannel的订阅者处理逻辑有调整：若第一个Flow中第二个订阅分支调用integrationGateway.process()后未将结果返回主流程，HTTP网关会判定主流程响应等待已完成，此时第二个Flow发送到同一临时通道的消息会被网关当作响应接收。
  • 你手动向replyChannel发送响应的时机可能晚于网关的超时或响应接收逻辑触发，导致网关已接收第二个Flow的输出，手动响应被丢弃。

2. replyChannel与errorChannel相同是否正常？ #

不正常。你为HTTP入站网关配置了.errorChannel(adapterErrorChannel())，说明期望使用独立的错误处理通道，但实际两者同为TemporaryReplyChannel，大概率是adapterErrorChannel()的实现存在问题——比如错误地从消息头中获取replyChannel作为错误通道返回，而非引用独立的全局错误通道。临时回复通道仅用于当前请求的响应返回，不能作为错误通道使用，否则会导致错误消息被当作响应返回，或干扰正常响应逻辑。

3. 不同Flow之间是否应共享replyChannel？ #

绝对不应该。TemporaryReplyChannel是请求绑定的专属通道，每个HTTP请求的临时通道仅用于该请求的响应传递。不同Flow（尤其是独立触发的Flow）共享该通道会导致响应混乱，出现“错误Flow的输出被当作目标响应返回”的问题。

修复建议 #

• 隔离消息头传播：在第二个Flow的入口处，过滤replyChannel和errorChannel等请求级头，例如使用.enrichHeaders(h -> h.removeHeaders(IntegrationHeaders.REPLY_CHANNEL, IntegrationHeaders.ERROR_CHANNEL))或HeaderFilter组件。
• 修正错误通道配置：确保adapterErrorChannel()返回独立的全局通道（如MessageChannel类型的Bean），而非从消息头获取的临时通道。
• 调整第一个Flow的响应链路：确保integrationGateway.process()的处理结果能正确返回给HTTP网关，或明确控制响应发送时机，避免网关提前结束等待。例如将手动发送响应的逻辑整合到Flow中，而非单独调用replyChannel.send()。
• 检查nullChannel的使用：确认nullChannel的使用不会意外触发消息发送到replyChannel，6.x中nullChannel的处理逻辑更严格，需确保消息到达nullChannel前无残留的响应发送逻辑。

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