MassTransit对接Azure Service Bus配置DLQ后出现MessageLockLostException异常

这个现象是MassTransit 7.2.3版本对接Azure Service Bus开启原生DLQ时的已知逻辑冲突，不属于配置错误：

• 当你配置了ConfigureDeadLetterQueueErrorTransport后，消费抛出异常时MassTransit会直接调用Azure Service Bus原生API将消息移入DLQ，这一步已经把消息从订阅队列移除，对应的消息锁也会被ASB自动回收。
• 7.2.3版本的旧消费逻辑中，消费失败流程结束后，框架仍会尝试执行默认的锁续期/状态更新操作，此时消息已经不存在于队列中，就会触发MessageLockLostException警告，该警告属于误报，不影响实际业务逻辑，消息已经正确投递到原生DLQ。
• 你注释掉该配置后，消息会走MassTransit默认的_error队列流转逻辑，不会提前触发消息移除，自然不会出现锁丢失警告。

根据你的实际场景可以选择以下方案：

• 方案1：直接忽略警告：你的配置逻辑完全符合预期，消息已经正确进入原生DLQ，该警告不会对业务产生任何影响，无需额外处理。
• 方案2：升级MassTransit版本：升级到8.0及以上版本，该版本已经修复了这个逻辑冲突，开启原生DLQ后不会再执行后续的无效锁操作，警告会自动消失。
• 方案3：日志过滤：如果不方便升级版本，可以在日志配置中过滤掉MassTransit分类下的MessageLockLostException警告，不影响其他正常报错的采集。

你当前的配置是正确的，已经完全实现了用Azure Service Bus原生DLQ替代MassTransit默认的_skipped、_error队列的需求，无需调整配置逻辑。

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