MassTransit配置非持久化却发送持久化消息，请求排查原因

嘿，这个错误我之前踩过坑！它的核心意思其实是：你发送消息时带的Exchange持久化配置，和服务器上已经存在的那个Exchange的配置对不上——哪怕你以为自己只把队列设成非持久化了。下面给你拆解几个大概率的原因和解决办法：

1. 别搞混队列和Exchange的持久化配置 #

你代码里设置的Durable=false是给队列用的，但错误提示里明确说的是Exchange（exchange 'QUEUENAMEHERE'）的durable参数不匹配：服务器上当前是false，但你的请求发过来的是true。

很多客户端SDK有个“坑”：当你发送消息时，如果指定的Exchange不存在，会自动帮你创建它，但默认是按持久化（durable=true）来创建的。如果之前你已经手动创建了一个durable=false的同名Exchange，那自然就冲突了。

2. 客户端SDK默认偷偷给Exchange开了持久化 #

检查下你发送消息的代码，是不是没显式指定Exchange的持久化属性？举个例子，用RabbitMQ .NET客户端的话，哪怕你没写Exchange声明的代码，有些场景下SDK会隐式帮你声明Exchange，而且默认用durable=true。

解决办法很直接：

• 显式声明Exchange时，把durable设为false，和服务器上现有的配置完全对齐：

  channel.ExchangeDeclare(exchange: "QUEUENAMEHERE",
                          type: ExchangeType.Direct,
                          durable: false); // 这里必须和服务器上Exchange的durable值一致
  

• 如果你不需要自动创建Exchange的功能，直接把客户端的自动声明开关关掉（不同SDK的设置方式不同，比如有些可以设autoDeclare=false）。

3. 旧连接缓存了过时的配置 #

有时候客户端的旧连接会缓存Exchange的配置信息，哪怕你改了代码，旧连接还是在用老参数发请求。这时候可以试试：

• 重启你的客户端应用，让所有连接重新建立；
• 登录服务器的管理界面（比如RabbitMQ的管理后台），确认那个Exchange的durable属性确实是false，别自己记错了。

4. 有人偷偷改了服务器上的Exchange配置 #

如果你的队列是绑定到这个Exchange的，说不定之前有同事或者运维改了Exchange的持久化属性？先确认服务器上Exchange的实际配置，再调整客户端的参数和它保持一致就行。

总的来说，这个问题的本质就是客户端请求里的Exchange参数必须和服务器上已存在的Exchange完全匹配，别只盯着队列的Durable设置，Exchange的配置也得同步上！

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