iloveeyjafjalla opened a new issue, #11356: URL: https://github.com/apache/rocketmq/issues/11356
### Before Creating the Bug Report - [x] I found a bug, not just asking a question, which should be created in [GitHub Discussions](https://github.com/apache/rocketmq/discussions). - [x] I have searched the [GitHub Issues](https://github.com/apache/rocketmq/issues) and [GitHub Discussions](https://github.com/apache/rocketmq/discussions) of this repository and believe that this is not a duplicate. - [x] I have confirmed that this bug belongs to the current repository, not other repositories of RocketMQ. ### Runtime platform environment OS: Windows 11 / Linux (proxy module, platform independent) ### RocketMQ version branch: develop Git commit id: 9ea2ccdc2b41445aee5e177e14e501d606f5a1ed (2026-10-08) ### JDK Version Compiler: Temurin 1.8.0_504 (target 1.8, same as CI) ### Describe the Bug `AdminSendMessage` (Proxy Admin gRPC surface) routes a message that carries a message group through a different hash than the gRPC data plane, so a FIFO group's messages can be split over several queues. The admin path hashes the group with plain modulo (`proxy/src/main/java/org/apache/rocketmq/proxy/grpc/admin/ProxyAdminGrpcService.java`, `selectQueue`): ```java int index = Math.floorMod(shardingKey.hashCode(), queues.size()); ``` the data plane hashes the same key with Guava's consistent hash (`proxy/src/main/java/org/apache/rocketmq/proxy/grpc/v2/producer/SendMessageActivity.java:414`): ```java int bucket = Hashing.consistentHash(shardingKey.hashCode(), writeQueues.size()); ``` The two functions disagree for the same key and queue count (for message group `groupA-fifo` over 3 writable queues, `floorMod` picks index 2 while `consistentHash` picks index 0), so a message injected through the admin surface lands on a queue that the group's own producers never write to. `selectQueue`'s own javadoc states the intent ("A FIFO message must keep going to the queue its message group hashes to") and `docs/proxy-admin.md` documents the admin send path as "system properties honoured for timer / FIFO messages", so the mapping is meant to match the data plane. Impact: per-group FIFO ordering is silently violated for that group (messages are only ordered within one queue), and a second consumer can pick up the admin message from the other queue. The RPC still answers with `OK`, so nothing tells the operator the group was split. ### Steps to Reproduce 1. Run a proxy with `grpcAdminServerEnable=true` and a topic that has at least 3 writable queues. 2. Produce FIFO messages for message group `g` with a gRPC producer — the data plane writes them to queue `Hashing.consistentHash(g.hashCode(), writeQueues.size())`. 3. Send a message for the same group through the admin surface: `AdminSendMessage` with `system_properties.message_group = "g"`. 4. Observe that the admin message is written to queue `Math.floorMod(g.hashCode(), writeQueues.size())`, which is usually a different queue than the group's messages use. ### Expected behavior A message the admin surface sends for a message group lands on the same queue the data plane hashes that group to, so the group keeps its FIFO order. ### Actual behavior The message can be written to a different queue than the group's messages (status `OK`, no warning). ### Additional context Minimal fix: use the same hash function the data plane uses in `ProxyAdminGrpcService#selectQueue`, and cover the parity with a unit test on the `QueueSelector` the RPC hands to `MessagingProcessor#sendMessage`. -- 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]
