如何从AmqpInboundChannelAdapter手动NACK消息？重试方案咨询

首先，你的更新方案是完全可行的，而且是处理这类重试后手动NACK场景的合理思路。咱们先拆解下原来的问题，再聊聊这个方案的优势和可以优化的地方。

为什么原来的setErrorChannel方案不生效？ #

当你给AmqpInboundChannelAdapter设置errorChannel时，默认生成的错误消息并不会完整保留原始AMQP消息的头部（比如AmqpHeaders.CHANNEL和AmqpHeaders.DELIVERY_TAG）。这是因为默认的错误消息构建逻辑只会携带部分上下文，不会把原始消息的所有头信息都传递过去，导致你的manualNack方法拿不到执行NACK所需的关键头部，自然无法完成操作。

你的更新方案为什么可行？ #

你自定义的nackStrategy和ErrorMessageSendingRecoverer组合解决了核心问题：

1. 保留原始消息头部：通过ErrorMessageUtils.INPUT_MESSAGE_CONTEXT_KEY获取到触发错误的原始消息，然后将原始消息的头部直接复制到错误消息中。这样manualNack方法就能正常获取到CHANNEL和DELIVERY_TAG这两个关键头，顺利执行basicNack操作。
2. 重试耗尽后触发NACK：ErrorMessageSendingRecoverer作为RecoveryCallback，会在重试模板的重试次数耗尽后，将错误消息发送到manualNackChannel，完美匹配你“重试失败后手动NACK”的需求。

几个需要注意的优化点 #

1. 避免重复重试逻辑：
   你在someListenerContainer里已经配置了adviceChain包含retryInterceptor（带3次重试和RejectAndDontRequeueRecoverer），同时又给AmqpInboundChannelAdapter设置了retryTemplate。这会导致重试逻辑重复执行，总重试次数可能超出你的预期。建议只在一个层面配置重试：要么用容器的adviceChain，要么用适配器的retryTemplate，不要同时启用，避免逻辑混淆。

2. 空指针安全优化：
   可以给自定义的nackStrategy加个空判断，避免inputMessage不是Message类型时出现异常：

   private ErrorMessageStrategy nackStrategy(){
       return (throwable, attributes) -> {
           Object inputMessage = attributes.getAttribute(ErrorMessageUtils.INPUT_MESSAGE_CONTEXT_KEY);
           if (inputMessage instanceof Message<?>) {
               return new ErrorMessage(throwable, ((Message<?>)inputMessage).getHeaders());
           }
           // 兜底处理，返回默认错误消息
           return new ErrorMessage(throwable);
       };
   }
   

3. 用内置策略简化代码：
   如果你使用的是Spring Integration 5.3及以上版本，可以直接用内置的AmqpMessageHeaderErrorMessageStrategy，它已经封装了保留AMQP头部的逻辑，不用自己写自定义策略：

   adapter.setRecoveryCallback(new ErrorMessageSendingRecoverer(manualNackChannel(), new AmqpMessageHeaderErrorMessageStrategy()));
   

总结 #

你的方案核心思路是正确的：确保错误消息携带原始AMQP的关键头部，这样才能在重试耗尽后执行手动NACK。只要调整好重试逻辑的一致性，再做些细节优化，这个方案就非常完善了。

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