[Bug] Proxy gRPC batch send returns one receipt for N messages, so SDKs fail the send although the broker stored the batch

[unbridled-41]

Before Creating the Bug Report

• I found a bug, not just a question.
• I searched open GitHub Issues and pull requests and found no duplicate.
• I confirmed that this bug belongs to Apache RocketMQ.

Runtime platform environment

All platforms; reproduced with a deterministic unit test on the current develop branch.

RocketMQ version

develop at ff8f6f74c

JDK Version

All

Describe the Bug

The v2 gRPC protocol defines SendMessageResponse.entries as one SendResultEntry per message of the request. The proxy, however, sends an N-message SendMessageRequest to the broker as one remoting batch send and forwards the single batch SendResult to SendMessageActivity#convertToSendMessageResponse, which builds exactly one response entry:

• LocalMessageService#sendMessage collapses msgList.size() > 1 into one MessageBatch and returns a single-element List<SendResult>.
• ClusterMessageService#sendMessage calls sendMessageAsync(..., msgList, ...) for msgList.size() != 1, which also returns one SendResult (comma-joined per-message ids, first message's queue offset).
• convertToSendMessageResponse iterates the result list one-to-one, so an N-message request gets a 1-entry response.

Every official v2 SDK validates the receipt count: rocketmq-clients Java ProducerImpl#send0 fails the send future with InternalErrorException("[Bug] due to an unknown reason from remote, received send receipt's quantity ... is not equal to sent message's quantity ...") when sendReceipts.size() != messages.size(). So although the broker has already stored all N messages, the caller sees the send fail — and the SDK's automatic retry sends the whole batch again, duplicating every message.

Steps to Reproduce

1. Send a SendMessageRequest with 3 messages through the proxy (gRPC v2, local or cluster mode).
2. Observe the broker stored 3 messages, but SendMessageResponse.entries has size 1 (offset = only the first message's, messageId = comma-joined batch ids).
3. rocketmq-clients Java/Go/C++/C# producers reject the response with the receipt-quantity error and retry, storing the batch a second time.

What Did You Expect to See?

SendMessageResponse.entries must contain one entry per request message, with the per-message messageId and queueOffset + i, the same way the remoting client expands batch results (ProduceAccumulator#splitSendResults).

What Did You See Instead?

One entry for the whole batch; SDKs fail the send although it was persisted, and retries duplicate the batch.

Additional Context

The client module already contains the intended expansion algorithm (ProduceAccumulator#splitSendResults: split comma-joined msgId/offsetMsgId, queueOffset + i per entry, and reuse the single result for inner-batch-message responses without per-message ids). Applying the same expansion in SendMessageActivity#convertToSendMessageResponse (where the original request is available) fixes local and cluster mode at once, and a regression test in SendMessageActivityTest fails on unmodified develop.

Corresponding PR

• PR [ISSUE #11049] Return one send receipt entry per message for proxy batch sends #11050

[RockteMQ-AI]

Issue Evaluation

Category: bug | Status: Confirmed

The reported issue has been verified against the current codebase.

Root Cause: The v2 gRPC proxy collapses N-message batch sends into a single SendResult, but SendMessageActivity#convertToSendMessageResponse builds only one response entry. SDKs validate receipt count and fail the send when entries.size() != messages.size(), causing retries that duplicate already-persisted messages.

Impact: Proxy gRPC batch send path (local and cluster mode). All v2 SDKs (Java/Go/C++/C#/Rust) reject the malformed response and retry, duplicating messages.

Severity: High — data duplication and send failures in production batch workloads.

Fix Status: PR #11050 addresses this by expanding the batch result into per-message entries in convertToSendMessageResponse, matching the existing ProduceAccumulator#splitSendResults algorithm.

---

Automated evaluation by RockteMQ-AI

[RockteMQ-AI]

Issue Evaluation

Category: bug | Status: Confirmed

Verified against the current develop branch. The batch send receipt mismatch is confirmed:

1. LocalMessageService#sendMessage (line 98): When msgList.size() > 1, messages are collapsed into a MessageBatch and sent as a single batch, returning one SendResult.
2. ClusterMessageService#sendMessage (line 68): For msgList.size() != 1, calls sendMessageAsync with the full list, also returning one SendResult.
3. SendMessageActivity#convertToSendMessageResponse (line 331): Iterates the result list one-to-one, so N-message request produces 1-entry response.

Root Cause: The proxy collapses N messages into a single batch send and returns one SendResult, but the gRPC v2 protocol expects one SendResultEntry per message.

Impact: Critical — All v2 SDK batch sends through the proxy fail with InternalErrorException, causing automatic retries that duplicate every message. The broker stores messages correctly but callers see failures.

Severity: Critical — data duplication + send failures for all batch sends via gRPC v2.

Fix direction: convertToSendMessageResponse should expand the single batch SendResult into N SendResultEntry items (one per message), using per-message offsets and message IDs from the batch result.

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

---

Automated evaluation by RockteMQ-AI

[RockteMQ-AI]

Issue Evaluation

Category: type/bug | Status: Confirmed

The issue is valid and well-analyzed. The Proxy gRPC batch send path returns a single SendMessageResponse for N messages, but the SDK expects one receipt per message. When the broker succeeds, the SDK cannot match the single response to N individual sends, causing it to report failure even though the messages were stored.

I see that PR #11050 has already been opened to address this. The fix approach (returning N receipts in the batch response) is correct and maintains protocol consistency with the SDK's expectations.

No further action needed from the evaluation side — the PR should resolve this.

---

Automated evaluation by github-manager