[ISSUE #S5] Clamp negative maxNum in IndexService.queryOffset

[zjncs]

Motivation

maxNum reaches IndexService.queryOffset straight from QueryMessageRequestHeader, where the field is only annotated @CFNotNull — no range validation. A negative value therefore survives the existing

maxNum = Math.min(maxNum, this.defaultMessageStore.getMessageStoreConfig().getMaxMsgsNumBatch());
List<Long> phyOffsets = new ArrayList<>(maxNum);

cap (min of a negative and a positive is still negative) and new ArrayList<>(maxNum) throws IllegalArgumentException: Illegal Capacity: -1 before the try block, so it propagates uncaught through DefaultMessageStore.queryMessage back to the request processor, answering the client with an opaque SYSTEM_ERROR.

Modifications

• Clamp maxNum to a minimum of 0 before the cap: Math.min(Math.max(maxNum, 0), maxMsgsNumBatch). A negative request now simply returns an empty QueryOffsetResult, consistent with maxNum == 0.

Verification

Fail-before (new test on unpatched code):

IndexServiceTest.testQueryOffsetWithNegativeMaxNum:87 » IllegalArgument Illegal Capacity: -1

Pass-after — full IndexServiceTest (5 existing + 1 new):

mvn -pl store test -Dtest='IndexServiceTest'
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[RockteMQ-AI]

Summary

Clamps negative maxNum to 0 before using it in ArrayList allocation — prevents IllegalArgumentException from propagating as an opaque SYSTEM_ERROR. Clean, minimal fix with a regression test.

LGTM.

---

Automated review by github-manager-bot