iloveeyjafjalla opened a new issue, #11364: URL: https://github.com/apache/rocketmq/issues/11364
### 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 The documented lite-topic filters are silently ignored, so a lite-scoped query is answered with the parent topic's data. The admin proto documents two filters: ```proto // DescribeGroupAccumulationRequest // Restrict the query to a single lite topic multiplexed onto the topics above. optional string lite_topic = 4; // ListConsumerConnectionRequest // Optional lite topic filter, multiplexed onto the topic above. optional string liteTopic = 4; ``` Neither is read anywhere in the admin implementation (`grep -rn "getLiteTopic" proxy/src/main/java/org/apache/rocketmq/proxy/grpc/admin/` finds nothing): `DescribeGroupAccumulation` only reads `group` and `topics`, and `ListConsumerConnection` only reads `group` and `topic`. Consequences: - `DescribeGroupAccumulation{group, topics:[parent], lite_topic:"liteA"}` returns `OK` with `accumulation` = the **whole parent topic's** accumulation and an empty `lite_topic_accumulation` map. For a group consuming several lite topics multiplexed onto one physical topic, that number is wrong by the sum of the other lite topics, and it looks like the scoped answer. - `ListConsumerConnection{group, topic:parent, liteTopic:"liteA"}` returns every online client of the group whose group-level subscription table contains the parent topic, including clients that never subscribed to `liteA`. - `DescribeGroupAccumulationResponse.lite_topic_accumulation` is never populated by any code path. This contradicts the contract the surface documents for itself (`docs/proxy-admin.md` §8 "Honest boundaries": the admin surface never fills a field it cannot truthfully supply, and unsupported variants are answered with an explicit status — which is what `QueryMessage` already does for its `subscription` / `lite_topic` / time-range variants). ### Steps to Reproduce 1. Run a proxy with `grpcAdminServerEnable=true`, a group consuming two lite topics (`liteA`, `liteB`) multiplexed onto one parent topic. 2. Call `DescribeGroupAccumulation` with `topics:[parent]` and `lite_topic:"liteA"`. 3. Compare with the number returned for `lite_topic:"liteB"` — they are identical, and both equal the parent topic's total. 4. Call `ListConsumerConnection` with `topic:parent, liteTopic:"liteA"` — clients subscribed only to `liteB` are returned. ### Expected behavior Either the filter is honored (a lite-scoped answer, and `lite_topic_accumulation` filled), or the request is refused with an explicit status saying the variant is not supported — never silently answered with the parent scope's data. ### Actual behavior The filter is ignored and the parent-scope data is returned with `OK`. ### Additional context The open-source broker exposes lite-topic lag only as a single total (`GET_LITE_GROUP_INFO` → `totalLagCount`), without the inflight / ready / deliver-delay split this response is built from, and per-client lite subscriptions are only known for the clients attached to the proxy that is asked (the listing RPCs are cluster-visible). A truthful implementation is therefore not available here, so the fix follows the surface's own rule and rejects the unsupported variant with `BAD_REQUEST`, documenting the boundary in `docs/proxy-admin.md` §8 / `docs/proxy-admin-zh.md` §8. -- 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]
