[ISSUE #10405] Fix orderly consumer retry message routed to wrong broker via TBW102 fallback

[qianye1001]

Summary

• Fix ConsumeMessageOrderlyService.sendMessageBack() and ConsumeMessagePopOrderlyService.sendMessageBack() to route retry messages to brokers that actually host the original topic, instead of falling back to TBW102 which routes to all brokers in the cluster.

Root Cause

When an orderly consumer's reconsume times reach maxReconsumeTimes, sendMessageBack() sends the retry message via getDefaultMQProducer().send(newMsg) — a normal producer send. Since the %RETRY% topic doesn't exist yet, the producer falls back to TBW102 (a system topic present on ALL brokers) for broker selection. This causes the %RETRY% topic to be auto-created on brokers that don't host the original topic.

Contrast with concurrent consumers: ConsumeMessageConcurrentlyService uses consumerSendMsgBack which targets msg.getBrokerName() directly — no TBW102 fallback.

Fix

Added trySendToTopicBroker() to both orderly service classes. It uses the consumer's existing topicSubscribeInfoTable (route info for the original topic) to select candidate brokers:

1. Prefer original broker — the broker where the message was consumed
2. Failover to other brokers hosting the topic — if the original broker is down
3. Final fallback to default send — only when route info is unavailable (should not happen in practice)

Impact

Scenario	Before	After
Original broker alive	May route to any broker (TBW102)	Routes to original broker ✓
Original broker down	Routes to any broker	Failover to other brokers hosting the topic ✓
All topic brokers down	Routes to any broker	Same (fallback)

No behavioral change for brokers that DO host the original topic. Backward compatible.

Test plan

• Verify trySendToTopicBroker prefers the original broker when available
• Verify failover to another broker when original broker send fails
• Verify fallback to default send when route info is empty
• Integration test: proxy cluster mode with multi-broker, orderly consumer hitting maxReconsumeTimes — %RETRY% should only appear on brokers hosting the original topic

Closes #10405

🤖 Generated with Claude Code

[codecov-commenter]

Codecov Report

❌ Patch coverage is 8.33333% with 44 lines in your changes missing coverage. Please review.
✅ Project coverage is 47.92%. Comparing base (a705dbc) to head (3692d1b).

Files with missing lines	Patch %	Lines
...nt/impl/consumer/ConsumeMessageOrderlyService.java	0.00%	24 Missing ⚠️
...impl/consumer/ConsumeMessagePopOrderlyService.java	16.66%	18 Missing and 2 partials ⚠️

Additional details and impacted files

@@              Coverage Diff              @@
##             develop   #10408      +/-   ##
=============================================
- Coverage      47.99%   47.92%   -0.07%     
+ Complexity     13271    13251      -20     
=============================================
  Files           1376     1376              
  Lines         100536   100582      +46     
  Branches       12983    12995      +12     
=============================================
- Hits           48249    48201      -48     
- Misses         46355    46439      +84     
- Partials        5932     5942      +10     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.