[Bug] gRPC FIFO batch sends ignore the message group when selecting a queue
- Dominant language
- Java
- Stars
- 22.6k
- Forks
- 12k
- Avg merge
- 3d 1h
- Merged PRs (30d)
- 27
Description
### Before Creating the Bug Report
- [x] I found a bug, not just a question.
- [x] I searched existing RocketMQ issues and pull requests and found no duplicate.
- [x] I confirmed the affected code belongs to this repository.
### Runtime platform environment
Any environment using the RocketMQ Proxy gRPC v2 producer path.
### RocketMQ version
Current `develop` branch (`7eee0fc366`).
### JDK Version
JDK 8.
### Describe the Bug
`SendMessageActivity.SendMessageQueueSelector` only reads `messageGroup` when a gRPC `SendMessageRequest` contains exactly one message.
For a FIFO batch, the selector therefore ignores the shared message group and falls back to the normal fault-aware queue-selection pipeline. Consecutive batches for the same FIFO message group may be sent to different queues, so their order is not preserved.
The lower Proxy client already supports encoding a message list as one `MessageBatch` and sending one `SEND_BATCH_MESSAGE` request. The missing pieces are FIFO-aware queue selection and batch-level validation at the gRPC boundary.
### Steps to Reproduce
1. Send multiple gRPC FIFO `SendMessageRequest` batches.
2. Put at least two messages in every request.
3. Use the same non-empty `messageGroup` for every message and every batch.
4. Observe queue selection across requests.
### What Did You Expect to See?
- All FIFO batches with the same message group select the same queue.
- Every request is encoded and sent to the Broker as one batch request.
- A batch is rejected unless its messages have a supported, consistent type and FIFO message group.
- Compressed batch messages are rejected; only uncompressed batch input is accepted.
- The encoded batch observes the Proxy message-size limit and a bounded message-count limit.
- The gRPC response contains one result entry per input message.
### What Did You See Instead?
The queue selector discards the FIFO message group whenever the request contains more than one message, allowing consecutive batches in the same logical FIFO stream to select different queues.
### Proposed Scope
Update the gRPC producer path to:
- select the queue using the FIFO message group for batch requests;
- validate batch type, FIFO group, encoded size, and message count;
- reject compressed batch messages;
- keep one `SEND_BATCH_MESSAGE` request to the Broker;
- expand the Broker batch result into ordered per-message gRPC result entries;
- add focused activity and protocol-level regression tests.
Contributor guide
Research direction
Start at SendMessageActivity.SendMessageQueueSelector and trace the gRPC producer path through the lower Proxy client and SEND_BATCH_MESSAGE protocol. Add focused activity and protocol-level regression tests covering FIFO queue selection, batch validation, size and count limits, compression rejection, one broker request, and ordered per-message results.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- grpc, java
- Domain
- api, distributed-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100