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
- Use an existing Lite consumer group bound to a parent topic.
- 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.
- 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.
Runtime platform environment
Windows, local broker unit tests; no running cluster is required for the regression test.
RocketMQ version
developatff8f6f74c560e391261ccd716707c6d20422e253(5.5.1).JDK Version
Amazon Corretto 8u482; Maven 3.9.11.
Describe the Bug
LiteManagerProcessor.getLiteGroupInfoforwards the request'stopKdirectly to the lag calculators whenliteTopicis absent or empty.GetLiteGroupInfoRequestHeader.checkFields()does not validate it.LiteConsumerLagCalculator.getLagCountTopKusestopKas the initial capacity of aPriorityQueue. 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
GET_LITE_GROUP_INFOwith that group, no specificliteTopic, andtopK=0ortopK=-1. The equivalent CLI input ismqadmin getLiteGroupInfo -n <namesrv> -p <parent-topic> -g <lite-group> -k 0.getLagCountTopKinstead 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_PARAMETERresponse with a clear valid range, before calling either lag calculator. Requests for a specific LiteTopic should continue to work withouttopK, 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), acceptingtopKin[1, 10000]for aggregate queries. Regression coverage includes null/empty LiteTopic, zero/negative/oversized values, accepted boundaries, and a specific-topic query with the defaulttopK.I searched existing issues and pull requests for
topKand the Lite lag calculator; the related merged PR #10424 optimizes timestamp lookup and does not add this validation.