iloveeyjafjalla opened a new issue, #11373: URL: https://github.com/apache/rocketmq/issues/11373
### 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 remoting server; a client sending POP / ACK / CHANGE_MESSAGE_INVISIBLETIME over remoting) ### 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 The proxy's remoting server routes POP and its acknowledgment codes to processors that cannot serve them, while the dedicated activities are constructed and never registered. `RemotingProtocolServer` creates the three activities: ```java this.popMessageActivity = new PopMessageActivity(pipeline, messagingProcessor); this.ackMessageActivity = new AckMessageActivity(pipeline, messagingProcessor); this.changeInvisibleTimeActivity = new ChangeInvisibleTimeActivity(pipeline, messagingProcessor); ``` and then registers other processors for their request codes: ```java remotingServer.registerProcessor(RequestCode.POP_MESSAGE, pullMessageActivity, this.pullMessageExecutor); remotingServer.registerProcessor(RequestCode.ACK_MESSAGE, consumerManagerActivity, this.updateOffsetExecutor); remotingServer.registerProcessor(RequestCode.CHANGE_MESSAGE_INVISIBLETIME, consumerManagerActivity, this.updateOffsetExecutor); ``` Consequences: - **POP_MESSAGE** is served by `PullMessageActivity`, which decodes a `PullMessageRequestHeader` and unboxes `requestHeader.getSysFlag()`; a POP request carries a `PopMessageRequestHeader`, so the decode/unbox cannot succeed and the POP never reaches the message path (the request fails instead of popping). The proxy does implement POP (`ConsumerProcessor` builds a `PopMessageRequestHeader`, `MessageService.popMessage`), and `PopMessageActivity` itself is a complete implementation (it decodes the POP header and forwards with `pollTime` as the timeout). - **ACK_MESSAGE / CHANGE_MESSAGE_INVISIBLETIME** are served by `ConsumerManagerActivity`, whose `processRequest0` switch has no case for them, so it returns `null`. `AbstractRemotingActivity.processRequest` only writes a response when it is non-null: ```java RemotingCommand response = this.processRequest0(ctx, request, context); if (response != null) { writeResponse(ctx, request, response); } ``` The requester therefore receives **no response at all**: it fails by its own timeout instead of getting an error, and the ack (or the invisible-time extension) is never applied — the message becomes visible again and is redelivered. ### Steps to Reproduce 1. Run a proxy (`mqproxy`) and a classic 4.x client in POP mode (`consumer.setClientRebalance(false)`, as in `example/.../PopConsumer.java`), or send the three request codes directly with the matching request headers. 2. Send `POP_MESSAGE` (200050) → the request is decoded as a pull request and fails instead of returning messages. 3. Send `ACK_MESSAGE` (200051) or `CHANGE_MESSAGE_INVISIBLETIME` (200053) → no response comes back; the client fails by timeout and the ack is not applied. ### Expected behavior `POP_MESSAGE` is served by `PopMessageActivity`, `ACK_MESSAGE` by `AckMessageActivity` and `CHANGE_MESSAGE_INVISIBLETIME` by `ChangeInvisibleTimeActivity` — the three activities that already exist for these codes. ### Actual behavior `POP_MESSAGE` goes to the pull activity (fails), the two acknowledgment codes go to the consumer-manager activity (no response, no error). ### Additional context Minimal fix: register the existing dedicated activities for those codes. Note that `QUERY_ASSIGNMENT` is still not served by this remoting server at all, which is a separate gap for the classic POP flow. -- 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]
