Runtime platform environment
Windows, local broker processor unit tests with mocked metadata and subscription registry.
RocketMQ version
develop at ff8f6f74c560e391261ccd716707c6d20422e253 (5.5.1).
JDK Version
Amazon Corretto 8u482; Maven 3.9.11.
Describe the Bug
GET_LITE_CLIENT_INFO validates that the requested consumer group is bound to the requested parent topic, then looks up the client's subscription by clientId alone. It does not compare the returned subscription's group and topic with the request.
Consequently, a query with a valid topic/group pair and a client belonging to another group can return SUCCESS. The response labels come from the request, while the subscription count, topics, and last-access information come from that other client. This produces misleading client diagnostics even when the client's subscription set is empty.
Steps to Reproduce
- Configure Lite groups
group1 and other_group bound to parent_topic.
- Register
client1 under other_group.
- Send
GET_LITE_CLIENT_INFO for (parent_topic, group1, client1).
- The processor returns success instead of rejecting the mismatched client subscription.
The accompanying regression test serializes the request header and calls processRequest. On the unmodified processor it fails with expected:<29> but was:<0> (INVALID_PARAMETER versus SUCCESS). The same missing check also affects a subscription whose parent topic differs from the requested topic.
What Did You Expect to See?
Validate both fields of an existing subscription against the requested group and parent topic before returning client details. Return INVALID_PARAMETER on mismatch, without a response body or the actual subscription's metadata in the error message.
What Did You See Instead?
SUCCESS, with the client's information reported under the requested topic/group regardless of the subscription's actual ownership.
Additional Context
LiteSubscriptionRegistryImpl.getOrCreateLiteSubscription already records the group and topic in each LiteSubscription, so no protocol or registry changes are required.
Matching subscriptions should still succeed, including an empty subscription set. An absent subscription should retain the existing success response with liteTopicCount=-1. No live-cluster or ACL behavior was tested; the reproduced issue is the inconsistent processor response.
Runtime platform environment
Windows, local broker processor unit tests with mocked metadata and subscription registry.
RocketMQ version
developatff8f6f74c560e391261ccd716707c6d20422e253(5.5.1).JDK Version
Amazon Corretto 8u482; Maven 3.9.11.
Describe the Bug
GET_LITE_CLIENT_INFOvalidates that the requested consumer group is bound to the requested parent topic, then looks up the client's subscription byclientIdalone. It does not compare the returned subscription's group and topic with the request.Consequently, a query with a valid topic/group pair and a client belonging to another group can return
SUCCESS. The response labels come from the request, while the subscription count, topics, and last-access information come from that other client. This produces misleading client diagnostics even when the client's subscription set is empty.Steps to Reproduce
group1andother_groupbound toparent_topic.client1underother_group.GET_LITE_CLIENT_INFOfor(parent_topic, group1, client1).The accompanying regression test serializes the request header and calls
processRequest. On the unmodified processor it fails withexpected:<29> but was:<0>(INVALID_PARAMETERversusSUCCESS). The same missing check also affects a subscription whose parent topic differs from the requested topic.What Did You Expect to See?
Validate both fields of an existing subscription against the requested group and parent topic before returning client details. Return
INVALID_PARAMETERon mismatch, without a response body or the actual subscription's metadata in the error message.What Did You See Instead?
SUCCESS, with the client's information reported under the requested topic/group regardless of the subscription's actual ownership.Additional Context
LiteSubscriptionRegistryImpl.getOrCreateLiteSubscriptionalready records the group and topic in eachLiteSubscription, so no protocol or registry changes are required.Matching subscriptions should still succeed, including an empty subscription set. An absent subscription should retain the existing success response with
liteTopicCount=-1. No live-cluster or ACL behavior was tested; the reproduced issue is the inconsistent processor response.