fix(broker): reject pop requests with non-positive maxMsgNums

[zjncs]

Motivation

processRequest only validated maxMsgNums > 32. A request with maxMsgNums = 0 fell through to the polling logic with a zero message budget instead of being rejected, and a negative value made new GetMessageResult pass the negative size to new ArrayList, throwing IllegalArgumentException from deep inside the pop path instead of a clean INVALID_PARAMETER response.

Modifications

Validate maxMsgNums >= 1 next to the existing upper-bound check.

Verification

Fail-before (new test, run against the unpatched code):

PopMessageProcessorTest#testProcessRequest_IllegalMaxMsgNums
java.lang.NullPointerException: Cannot invoke "MessageStoreConfig.isTimerWheelEnable()" because
"MessageStore.getMessageStoreConfig()" is null -- PopMessageProcessorTest.testProcessRequest_IllegalMaxMsgNums:261
(the maxMsgNums=0 request was not rejected and fell through into the polling path)

Pass-after:

Tests run: 9, Failures: 0, Errors: 0, Skipped: 0 -- PopMessageProcessorTest

[Copilot]

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

[RockteMQ-AI]

Summary

Input validation fix: reject pop requests with non-positive maxMsgNums before processing. Simple guard clause with test coverage.

LGTM — clean defensive check.

---

Automated review by github-manager-bot