基于MassTransit的Azure Service Bus订阅服务消费非MassTransit消息遇400错误

我之前帮团队排查过一模一样的问题，核心原因是MassTransit对Azure Service Bus消息的格式有默认的强规范要求，而你的第三方发布服务没遵循这些规则，导致MassTransit在解析消息时触发了无效的GET请求，最终抛出400 Bad Request异常。

下面是一步步的解决思路和方案：

1. 先检查第三方消息的核心属性 #

MassTransit默认依赖两个关键消息属性，缺失或格式不对都会触发解析错误：

• ContentType：必须设置为 application/json（如果你的消息是JSON格式），很多第三方服务默认会用text/plain或者其他类型，这会让MassTransit无法正确解析消息体。
• MessageType：这是MassTransit用来识别消息对应CLR类型的标识，格式需要是类似 ["YourApp.Messages.OrderCreated, YourApp.Messages"] 的字符串数组（单个类型也可以是字符串）。如果第三方服务没加这个属性，MassTransit会不知道该把消息反序列化成什么类型，进而引发后续错误。

如果能修改第三方发布服务，直接补上这两个属性，问题大概率就能解决。

2. 无法修改第三方服务？用MassTransit的原始JSON解析器 #

如果第三方服务不能改，那可以让MassTransit跳过默认的类型校验，直接按原始JSON解析消息。只需要在配置ReceiveEndpoint时添加UseRawJsonMessageDeserializer()：

services.AddMassTransit(x =>
{
    x.AddConsumer<YourMessageConsumer>();

    x.UsingAzureServiceBus((context, cfg) =>
    {
        cfg.Host("your-azure-service-bus-connection-string");

        cfg.ReceiveEndpoint("your-subscription-name", e =>
        {
            // 启用原始JSON解析，不需要MassTransit的MessageType元数据
            e.UseRawJsonMessageDeserializer();
            e.ConfigureConsumer<YourMessageConsumer>(context);
        });
    });
});

使用这个解析器后，MassTransit会直接把消息体反序列化成你消费者指定的类型，不需要依赖第三方消息的额外属性。

3. 排查Azure Service Bus订阅规则 #

有时候订阅规则设置不当也会导致奇怪的400错误，比如规则里过滤了必要的消息属性，或者规则表达式有误。可以登录Azure Portal，查看对应订阅的规则，确保没有过滤掉ContentType或其他关键字段，或者暂时清空规则测试一下。

4. 查看完整异常栈定位问题 #

你提供的异常信息被截断了，建议打开MassTransit的详细日志（把日志级别设为Debug），获取完整的异常调用栈，这样能更精准地定位是在消息解析、类型匹配还是其他环节出的问题。

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