3219378872 opened a new issue, #11232: URL: https://github.com/apache/rocketmq/issues/11232
### Search before asking I checked the current open issues/PRs and searched all states for `ListSubscription`, `DescribeSubscription`, and `resolveGroups`. #10826 introduced these RPCs; the open client-query work in #10603 implements a different API and does not modify this path. ### What happened? In cluster-mode Proxy Admin, querying subscriptions by **topic only** can return an empty successful response for an online gRPC consumer, although querying the same consumer by **group** returns its subscription. `ListSubscription` and `DescribeSubscription` share `resolveGroups(topic, group)`. When only a topic is supplied, that method discovers candidate groups exclusively through the brokers' `QUERY_TOPIC_CONSUME_BY_WHO`. The later `collectConnections` step can already read Proxy-side consumers, but it never gets called for a group omitted at the discovery step. A newly connected gRPC SimpleConsumer is registered in the Proxy's consumer manager. Before it has consumed/committed any offsets, the broker need not have either a consumer registration or an offset entry for this group, so the broker cannot discover the group. The Proxy already has the live topic/group registration needed to answer the request. This makes a topic-level diagnostic say that there are no subscriptions while a group-level diagnostic shows the online client. ### Expected behavior Topic-only subscription queries should include matching online groups known to the Proxy as well as groups discovered from the brokers, deduplicating groups present in both sources. Existing group-only queries and topic filtering should keep their behavior. ### Reproduction Baseline: `develop` at `78b96bc5e21216cd7896efae08f90c5cde4cae53`. 1. Register a gRPC consumer for a new group/topic on a cluster-mode Proxy, without receiving messages or committing offsets yet. 2. Call `ListSubscription` on the admin port with only `group` populated: the group/topic subscription is present. 3. Call `ListSubscription` with only `topic` populated: the response is `OK` with zero subscriptions. 4. Repeat with `DescribeSubscription`: the group query shows the client; the topic query returns no client subscriptions. Reproduced with a live isolated NameServer and Broker, a cluster-mode `DefaultMessagingProcessor` / `GrpcMessagingApplication`, the real broker-facing Admin gateway, and an official `rocketmq-client-java:5.2.2` SimpleConsumer running in a separate JVM. The SDK is built with a topic subscription and is never asked to receive or acknowledge messages. No discovery or consumer manager is mocked. Observed on the same live state: ```text ListSubscription(group): OK, 1 subscription ListSubscription(topic): OK, 0 subscriptions DescribeSubscription(group): OK, 1 client subscription DescribeSubscription(topic): OK, 0 client subscriptions ``` Controls confirmed that the Proxy's topic/group index contains the group, the broker's consumer index and committed-offset index do not contain it, and a real `MQAdminExt.queryTopicConsumeByWho(topic)` returns an empty group set. The test's expectation of one topic-query result fails on the unchanged baseline. The proto explicitly describes `ListSubscription` as “subscription relationships filtered by topic and/or group” and `DescribeSubscription` as subscriptions “reported by each individual client”; these are online-subscription queries, not historical consumer-offset queries. ### Version Current `develop`, Proxy Admin introduced by #10826. ### Are you willing to submit PR? Yes. I propose merging the Proxy-side `ConsumerManager.queryTopicConsumeByWho(topic)` result into topic-based group discovery, retaining broker discovery and the existing downstream subscription filtering. -- 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]
