iloveeyjafjalla opened a new issue, #11377: URL: https://github.com/apache/rocketmq/issues/11377
### 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: any (proxy module, admin gRPC surface) ### 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 `VerifyMessage` reports every failed consumption as `MESSAGE_CORRUPTED`, including the outcomes the proto grades separately. The handler looks only at `CMResult.CR_SUCCESS` and answers `MESSAGE_CORRUPTED` for everything else: ```java if (consumeResult == CMResult.CR_SUCCESS) { respond(responseObserver, VerifyMessageResponse.newBuilder().setStatus(ok()).build()); } else { respond(responseObserver, VerifyMessageResponse.newBuilder() .setStatus(err(Code.MESSAGE_CORRUPTED, "client " + clientId + " failed to consume message " + messageId + ...)) .build()); } ``` The consumed outcome is graded on both sides of the call: - a gRPC client's answer is mapped by `ClientActivity#buildConsumeMessageDirectlyResult`: `Code.OK` → `CR_SUCCESS`, `Code.FAILED_TO_CONSUME_MESSAGE` → `CR_LATER`, `Code.MESSAGE_CORRUPTED` → `CR_RETURN_NULL`; - when nothing is consumed, the relay result itself carries the reason (e.g. `SYSTEM_ERROR` with "client … is not connected to this cluster"). With the current code all of those become "the message is corrupted": | actual outcome | proto code for it | reported | |---|---|---| | client asked for a retry (`CR_LATER`, i.e. client said `FAILED_TO_CONSUME_MESSAGE`) | `FAILED_TO_CONSUME_MESSAGE = 60000` ("Generic code for failed message consumption") | `MESSAGE_CORRUPTED = 40016` | | client threw while consuming (`CR_THROW_EXCEPTION` / `CR_EXCEPTION`) | no corruption claim is justified | `MESSAGE_CORRUPTED` | | client never answered because it is offline (`consumeResult == null`, relay remark says so) | — | `MESSAGE_CORRUPTED` | A dashboard or an automation that reacts to `MESSAGE_CORRUPTED` treats a healthy message as corrupted whenever the client simply refused or was offline, instead of retrying or fixing the client. The class's own javadoc says the surface returns graded errors "so callers can tell … from 'internal error'". ### Steps to Reproduce 1. Run a proxy with `grpcAdminServerEnable=true` and a client whose `VerifyMessage` answer is not OK (e.g. a gRPC client that reports `FAILED_TO_CONSUME_MESSAGE` for the message). 2. Call `VerifyMessage` for that client and message. 3. The status is `MESSAGE_CORRUPTED` although the client reported a failed consumption. ### Expected behavior `MESSAGE_CORRUPTED` only when the client actually reports the message as corrupt (`CR_RETURN_NULL`, which is what the gRPC client sends for `Code.MESSAGE_CORRUPTED`); every other failed outcome is graded as `FAILED_TO_CONSUME_MESSAGE`, with the relay's own remark in the message when the client never answered. ### Actual behavior `MESSAGE_CORRUPTED` for all of them. ### Additional context Fix: pick the status code from the reported outcome instead of the binary success check. -- 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]
