Palaiologos1453 opened a new issue, #11055: URL: https://github.com/apache/rocketmq/issues/11055
### Runtime platform environment Windows, local broker unit tests; no running cluster is required for the regression test. ### RocketMQ version `develop` at `ff8f6f74c560e391261ccd716707c6d20422e253` (5.5.1). ### JDK Version Amazon Corretto 8u482; Maven 3.9.11. ### Describe the Bug `LiteManagerProcessor.getLiteGroupInfo` forwards the request's `topK` directly to the lag calculators when `liteTopic` is absent or empty. `GetLiteGroupInfoRequestHeader.checkFields()` does not validate it. `LiteConsumerLagCalculator.getLagCountTopK` uses `topK` as the initial capacity of a `PriorityQueue`. Zero and negative values are invalid constructor arguments. Large positive values also control the initial backing-array allocation without a server-side bound. ### Steps to Reproduce 1. Use an existing Lite consumer group bound to a parent topic. 2. Send `GET_LITE_GROUP_INFO` with that group, no specific `liteTopic`, and `topK=0` or `topK=-1`. The equivalent CLI input is `mqadmin getLiteGroupInfo -n <namesrv> -p <parent-topic> -g <lite-group> -k 0`. 3. The processor reaches `getLagCountTopK` instead of rejecting the invalid parameter. The accompanying processor regression test serializes request headers and invokes `processRequest`. It fails on the unmodified implementation because the invalid request reaches the mocked lag calculator. The constructor behavior above is established from the source path; a live-cluster run and large allocations were not attempted. ### What Did You Expect to See? An `INVALID_PARAMETER` response with a clear valid range, before calling either lag calculator. Requests for a specific LiteTopic should continue to work without `topK`, since that path does not use it. ### What Did You See Instead? The aggregate query accepts an unchecked heap capacity and reaches the calculator instead of returning a parameter error. ### Additional Context A small fix can reuse the processor's existing `MAX_RETURN_COUNT` (10,000), accepting `topK` in `[1, 10000]` for aggregate queries. Regression coverage includes null/empty LiteTopic, zero/negative/oversized values, accepted boundaries, and a specific-topic query with the default `topK`. I searched existing issues and pull requests for `topK` and the Lite lag calculator; the related merged PR #10424 optimizes timestamp lookup and does not add this validation. -- 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]
