qianye1001 commented on issue #10405:
URL: https://github.com/apache/rocketmq/issues/10405#issuecomment-4570158061

   ## 🔍 Automated Issue Analysis
   
   **Status**: Bug confirmed ✅
   **Priority**: P2 (Medium) — Affects multi-broker clusters using orderly 
consumer with retry
   **Affected Modules**: broker (ClientManageProcessor, 
AbstractSendMessageProcessor)
   
   ### Root Cause
   
   When an orderly consumer reaches `maxReconsumeTimes`, the 
`%RETRY%<consumerGroup>` topic is created on **all** brokers, including those 
that don't host the original topic. Three contributing factors:
   
   1. **`MQClientInstance.java:672-699`** — `sendHeartbeatToAllBroker()` sends 
heartbeat to every broker
   2. **`ClientManageProcessor.java:117-123`** — Broker unconditionally creates 
`%RETRY%` topic on heartbeat without checking if it hosts any subscribed topic
   3. **`AbstractSendMessageProcessor.java:507-511`** — Fallback retry topic 
creation in `msgCheck` also lacks validation
   
   ### Proposed Fix
   
   Add a guard condition in two code paths:
   1. **`ClientManageProcessor.java`** (heartbeat path) — Before creating 
`%RETRY%` topic, verify that this broker hosts at least one non-system topic 
the consumer subscribes to
   2. **`AbstractSendMessageProcessor.java`** (msgCheck fallback) — Same 
validation before fallback creation
   
   The guard uses existing `containsTopic()` API — O(1) ConcurrentHashMap 
lookup, negligible overhead.
   
   ### Backward Compatibility
   
   - No protocol or config changes
   - Rolling upgrade safe
   - Existing orphaned retry topics unaffected (only prevents future creation)
   - Graceful fallback when ConsumerGroupInfo is unavailable
   
   ### Risk: LOW
   
   Simple guard condition using battle-tested APIs. Heartbeat cycle provides 
natural eventual consistency.
   
   ---
   
   **Full spec** saved to `spec_v1.md` in the automated fix workspace.
   
   📋 **Next Steps**: Awaiting community review. Reply `/approve` to proceed 
with PR creation, `/revise` to request changes, or `/reject` to dismiss.
   
   *This analysis was generated automatically by the RocketMQ Issue Bot.*
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to