[Bug] Incorrect queue permissions in gRPC QueryRouteResponse when read/write queue counts differ

[Kris20030907]

Before Creating the Bug Report

• I found a bug, not just asking a question, which should be created in GitHub Discussions.

• I have searched the GitHub Issues and GitHub Discussions of this repository and believe that this is not a duplicate.

• I have confirmed that this bug belongs to the current repository, not other repositories of RocketMQ.

Runtime platform environment

Not platform-specific.

RocketMQ version

develop

JDK Version

JDK17

Describe the Bug

When the gRPC proxy builds QueryRouteResponse, the permission of each MessageQueue can be incorrect if readQueueNums and writeQueueNums are different.

The problem is in RouteActivity#genMessageQueueFromQueueData.

QueueData uses queue ids as ranges:

• readable queues: 0 .. readQueueNums - 1
• writable queues: 0 .. writeQueueNums - 1

So when a topic has both read and write permission, the overlapping queue ids should be marked as READ_WRITE.

However, the current implementation calculates the number of read-only, write-only, and read-write queues first, then appends them in groups while increasing the queue id. This preserves the count of each permission type, but may assign the permission to the wrong queue id.

For example, with:

• readQueueNums = 4
• writeQueueNums = 8
• perm = PERM_READ | PERM_WRITE

The expected result is:

• queue ids 0..3: READ_WRITE
• queue ids 4..7: WRITE

But the current implementation returns:

• queue ids 0..3: WRITE
• queue ids 4..7: READ_WRITE

So the route response exposes incorrect per-queue permissions to gRPC clients.

Steps to Reproduce

1. Create a QueueData with:
   • readQueueNums = 4
   • writeQueueNums = 8
   • perm = PERM_READ | PERM_WRITE
2. Call RouteActivity#genMessageQueueFromQueueData.
3. Check the generated MessageQueue list in the returned route response.

A similar issue can also be reproduced with:

• readQueueNums = 8
• writeQueueNums = 4
• perm = PERM_READ | PERM_WRITE

What Did You Expect to See?

The permission should be calculated by queue id.

For readQueueNums = 4, writeQueueNums = 8, and PERM_READ | PERM_WRITE:

• queue id 0: READ_WRITE
• queue id 1: READ_WRITE
• queue id 2: READ_WRITE
• queue id 3: READ_WRITE
• queue id 4: WRITE
• queue id 5: WRITE
• queue id 6: WRITE
• queue id 7: WRITE

In general:

• id < readQueueNums means the queue is readable
• id < writeQueueNums means the queue is writable
• if both conditions are true, the permission should be READ_WRITE

What Did You See Instead?

The current implementation returns the correct number of queues for each permission type, but assigns those permissions to the wrong queue ids.

For readQueueNums = 4, writeQueueNums = 8, and PERM_READ | PERM_WRITE, it returns:

• queue id 0: WRITE
• queue id 1: WRITE
• queue id 2: WRITE
• queue id 3: WRITE
• queue id 4: READ_WRITE
• queue id 5: READ_WRITE
• queue id 6: READ_WRITE
• queue id 7: READ_WRITE

This is inconsistent with how RocketMQ builds readable and writable queues from QueueData.

Additional Context

The issue is not about the total number of queues. The total count is correct.

The problem is that MessageQueue.id is part of the queue identity, so permission needs to match the actual queue id. Grouping permissions first and assigning ids afterwards can produce a route response where clients see a readable/writable status that belongs to a different queue id.

The internal route selection logic also builds read/write queues by iterating queue ids from 0 to readQueueNums - 1 or writeQueueNums - 1, which confirms that the permission should be derived per queue id rather than by grouped counts.

[Kris20030907]

I also checked the Java SDK side to see whether this is only a response display issue.

The queue permission from QueryRouteResponse is not ignored by the Java SDK. The route data is parsed and used to build local producer / consumer load balancers.

Route fetch path in Java SDK:

• ClientImpl#fetchTopicRoute0 sends QueryRouteRequest, reads response.getMessageQueuesList(), and constructs TopicRouteData.
• TopicRouteData wraps every protobuf MessageQueue as MessageQueueImpl.
• MessageQueueImpl stores both messageQueue.getId() and Permission.fromProtobuf(messageQueue.getPermission()).

Relevant code path:

• client/src/main/java/org/apache/rocketmq/client/java/impl/ClientImpl.java
  • fetchTopicRoute0: response.getMessageQueuesList() -> new TopicRouteData(messageQueuesList)
• client/src/main/java/org/apache/rocketmq/client/java/route/TopicRouteData.java
  • constructor wraps every protobuf MessageQueue
• client/src/main/java/org/apache/rocketmq/client/java/route/MessageQueueImpl.java
  • stores queueId = messageQueue.getId()
  • stores permission = Permission.fromProtobuf(messageQueue.getPermission())

The producer load balancer filters queues by this permission:

topicRouteData.getMessageQueues().stream()
    .filter(mq -> mq.getPermission().isWritable() &&
        Utilities.MASTER_BROKER_ID == mq.getBroker().getId())

So if the server returns wrong per-queue permissions, the Java SDK producer can build a wrong local writable queue set. For example, with:

• readQueueNums = 8
• writeQueueNums = 4
• perm = PERM_READ | PERM_WRITE

The real writable queues should be ids 0..3, but the old server-side route generation can mark ids 4..7 as READ_WRITE. The Java SDK would then treat ids 4..7 as writable and exclude ids 0..3 from its local publishing load balancer.

The consumer side has the same kind of dependency:

topicRouteData.getMessageQueues().stream()
    .filter(SubscriptionLoadBalancer::isReadableMasterQueue)

where isReadableMasterQueue checks:

mq.getPermission().isReadable()

So with readQueueNums = 4 and writeQueueNums = 8, the Java SDK consumer can build a local readable queue set using ids 4..7, while the actual readable queues are ids 0..3.

One nuance: in the current gRPC proxy implementation, the actual send / receive path does another server-side queue selection before talking to the broker.

For send:

• Java SDK chooses a local MessageQueueImpl from PublishingLoadBalancer.
• The selected queue id is written into message system properties.
• But SendMessageActivity creates a SendMessageQueueSelector, and ProducerProcessor builds the final SendMessageRequestHeader using the server-side selected AddressableMessageQueue#getQueueId().

For receive:

• Java SDK chooses a local MessageQueueImpl from SubscriptionLoadBalancer.
• It sends the selected MessageQueue in ReceiveMessageRequest.
• But ReceiveMessageActivity currently uses the broker name from the request and then selects from the server-side read selector.

So in the current Java SDK + gRPC proxy flow, the wrong route response does affect the SDK's local route view and load balancer candidates, but the server-side proxy can mask part of the issue when executing send / receive because it reselects queues internally.

Still, the route response itself is incorrect: MessageQueue.id and MessageQueue.permission no longer describe the same physical queue. Any client that relies on the per-queue permission directly, including Java SDK route filtering logic, can observe a wrong route view.

[RockteMQ-AI]

Issue Evaluation

Category: type/bug | Status: Confirmed

The reported issue has been verified against the current codebase on develop branch.

Root Cause:

In RouteActivity#genMessageQueueFromQueueData (line 241–299), when perm is both readable and writable, the code correctly calculates the counts of read-only (r), write-only (w), and read-write (rw) queues:

rw = Math.min(writeQueueNums, readQueueNums);
r = readQueueNums - rw;
w = writeQueueNums - rw;

However, it then assigns queue IDs in the wrong order: read-only first → write-only second → read-write last. This means queue IDs 0..r-1 get READ, r..r+w-1 get WRITE, and r+w..total-1 get READ_WRITE.

Per the QueueData convention (confirmed by MQClientInstance), queue IDs are ranges:

• IDs 0..readQueueNums-1 are readable
• IDs 0..writeQueueNums-1 are writable
• Overlap (0..min(read,write)-1) should be READ_WRITE

So the correct order should be: read-write first → write-only → read-only (or equivalently, derive permission per queue ID based on whether id < readQueueNums and/or id < writeQueueNums).

Why existing tests didn't catch it: The test partitionWith4R8WPermRW only asserts the count of each permission type (4 WRITE + 4 READ_WRITE), but does not verify which queue IDs received which permission.

Impact: gRPC clients receive incorrect per-queue permissions in QueryRouteResponse. This could cause clients to incorrectly skip sending to or reading from specific queues.

Severity: Medium — functional correctness issue for topics with asymmetric read/write queue counts.

An automated fix proposal will be generated. Reply /approve to proceed with PR generation.

---

Automated evaluation by github-manager-bot