Palaiologos1453 opened a new issue, #11059: URL: https://github.com/apache/rocketmq/issues/11059
### 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 1. Configure Lite groups `group1` and `other_group` bound to `parent_topic`. 2. Register `client1` under `other_group`. 3. Send `GET_LITE_CLIENT_INFO` for `(parent_topic, group1, client1)`. 4. 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. -- 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]
