iloveeyjafjalla opened a new issue, #11358: URL: https://github.com/apache/rocketmq/issues/11358
### 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, `-pm local`, 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 When the proxy runs in LOCAL mode (`-pm local`, proxy and broker in one process) with the admin gRPC server enabled (`grpcAdminServerEnable=true`), the client-directed admin RPCs never observe the client's answer and always run into the relay timeout. The Proxy Admin surface (`ProxyAdminGrpcService#relayConsumerRunningInfo` / `relayConsumeMessageDirectly`) writes a `ProxyRelayRequest` that carries its own future into the client's channel and waits on it: ```java ProxyRelayRequest relayRequest = ProxyRelayRequest.createRequestCommand( RequestCode.GET_CONSUMER_RUNNING_INFO, header, future); channelInfo.getChannel().writeAndFlush(relayRequest); ... return withTimeout(future, relayTimeoutMillis(), ...); ``` `ClusterProxyRelayService` bridges the relay future back to that caller future (`bridgeToCaller`), but `LocalProxyRelayService` — the implementation selected by `LocalServiceManager` when the proxy is embedded in the broker — only synthesizes a remoting response into the broker's response table: ```java future.thenAccept(proxyOutResult -> { ... nettyRemotingAbstract.processResponseCommand(simpleChannel.getChannelHandlerContext(), remotingCommand); }); return future; ``` That synthesized response belongs to the broker's mqadmin path; for a `ProxyRelayRequest` there is no remoting request waiting for it (the command's opaque is not in the broker's response table), while the in-process caller that attached its future to the command is never completed. Impact in LOCAL mode: - `GetConsumerRunningInfo`, `PrintThreadStackTrace` and `VerifyMessage` stall for the full relay timeout (`grpcProxyRelayRequestTimeoutInSeconds + 1`, 6 s by default) and then fail. For `VerifyMessage` / `PrintThreadStackTrace` that is the whole RPC; for `GetConsumerRunningInfo` the timeout also takes the degraded fallback path, which then reports a wrong cause — "client ... is not connected to this cluster" for a remoting client that is connected, or "a gRPC v2 client does not report ..." for an attached gRPC client. Note that this is specific to the in-process caller: the mqadmin path through the broker's own remoting server (the one the existing `LocalProxyRelayServiceTest` covers) is unaffected. ### Steps to Reproduce Unit-level, with the local relay service: 1. Create a `ProxyRelayRequest` for `GET_CONSUMER_RUNNING_INFO` / `CONSUME_MESSAGE_DIRECTLY` and attach a caller `CompletableFuture` (`ProxyRelayRequest.createRequestCommand(code, header, callerFuture)`). 2. Call `LocalProxyRelayService#processGetConsumerRunningInfo` / `#processConsumeMessageDirectly` with it, and complete the returned relay future with the result the client answered over the telemetry channel. 3. The caller future stays incomplete (`callerFuture.isDone()` is `false`), while the cluster implementation completes it with the same result. End-to-end: start `mqbroker` with the embedded proxy in local mode (`grpcAdminServerEnable=true`), connect a client, and call `GetConsumerRunningInfo` / `VerifyMessage` on the admin port — the call returns after ~6 s with an error instead of the client's answer. ### Expected behavior The relay outcome reaches the in-process caller, exactly as it does in CLUSTER mode, so the admin RPC answers with the client's data. ### Actual behavior The caller future is never completed; the RPC fails after the relay timeout. ### Additional context Fix: bridge the relay future to the caller future in `LocalProxyRelayService` as well (keep the existing remoting-response synthesis for plain `RemotingCommand`s, which is what the broker's mqadmin path needs), and share the bridging helper between the cluster and local implementations instead of keeping it private to the cluster one. -- 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]
