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.
- Register a gRPC consumer for a new group/topic on a cluster-mode Proxy, without receiving messages or committing offsets yet.
- Call
ListSubscription on the admin port with only group populated: the group/topic subscription is present.
- Call
ListSubscription with only topic populated: the response is OK with zero subscriptions.
- 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:
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.
Search before asking
I checked the current open issues/PRs and searched all states for
ListSubscription,DescribeSubscription, andresolveGroups. #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.
ListSubscriptionandDescribeSubscriptionshareresolveGroups(topic, group). When only a topic is supplied, that method discovers candidate groups exclusively through the brokers'QUERY_TOPIC_CONSUME_BY_WHO. The latercollectConnectionsstep 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:
developat78b96bc5e21216cd7896efae08f90c5cde4cae53.ListSubscriptionon the admin port with onlygrouppopulated: the group/topic subscription is present.ListSubscriptionwith onlytopicpopulated: the response isOKwith zero subscriptions.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 officialrocketmq-client-java:5.2.2SimpleConsumer 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:
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
ListSubscriptionas “subscription relationships filtered by topic and/or group” andDescribeSubscriptionas 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.