Azure Service Bus订阅过滤器失效问题求助

核心现象 #

• 原基于Subject/Label的GUID过滤规则突然失效，发送到主题的消息消失；新增1=1规则的默认订阅后，消息正常流入该订阅
• 经Azure Service Bus Explorer验证，消息的Subject、CorrelationID与过滤器中的GUID完全匹配，切换为CorrelationID、ReplyTo字段过滤仍无效
• 唯一前置变更：同Service Bus命名空间新增Queue，另一应用消费该Queue消息后，将消息转发至原消息ReplyTo指定的主题/订阅（管道分隔GUID），并移除ReplyTo字段

分步排查要点 #

1. 校验过滤器语法与字段准确性 #

• 确认SQL过滤器的字符串格式：GUID必须用单引号包裹，例如Subject = '00000000-0000-0000-0000-000000000000'，未加单引号会被SQL解析为标识符而非字符串，直接导致匹配失败
• 检查字段名大小写：Azure Service Bus系统字段严格区分大小写，比如CorrelationId（注意大写I）、Subject、Label，避免拼写错误

2. 深度验证消息属性一致性 #

• 在Service Bus Explorer中查看消息的系统属性与自定义属性，确认过滤字段是系统属性还是自定义属性（比如Label是系统字段，不要和自定义属性混淆）
• 检查GUID值是否存在不可见字符：将消息中的GUID复制到文本编辑器，对比过滤器中GUID的字符长度，排查空格、换行等隐性差异

3. 排查订阅规则冲突与优先级 #

• 检查目标订阅的所有规则：每个订阅可配置多条规则，若存在否定规则（如NOT Subject = 'xxx'），会直接排除符合条件的消息
• 确认规则的匹配逻辑：若订阅同时存在多个规则，只要匹配任意一条就会接收消息，但错误规则可能导致无匹配

4. 定位新增Queue操作的潜在影响 #

• 检查命名空间配额：查看Azure门户中Service Bus命名空间的消息总数、连接数等指标，确认是否触发配额限制导致路由异常
• 验证转发消息的正确性：
  • 检查转发应用是否误修改消息PartitionKey：若主题为分区类型，PartitionKey不匹配可能导致过滤器失效
  • 确认消息的To字段是否指向目标主题：在1=1订阅中查看消息的To属性，排查是否发送到了错误地址
• 排查转发逻辑是否篡改了过滤依赖的字段：比如是否意外覆盖了Subject、CorrelationID的值

5. 检查Service Bus服务状态 #

• 登录Azure门户查看命名空间的健康状态，排查是否存在服务中断、警告日志
• 查看主题与订阅的指标：关注「消息流入量」「订阅匹配消息数」，确认消息确实到达主题，且订阅过滤器无匹配记录

6. 最简测试验证路由逻辑 #

• 创建测试订阅，配置极简过滤器（如Subject = '你的测试GUID'），手动发送测试消息到主题，验证是否能正常接收
• 测试无过滤规则的默认订阅，确认主题本身的消息接收与路由功能正常

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