unbridled-41 opened a new pull request, #5985: URL: https://github.com/apache/rocketmq-dashboard/pull/5985
### Which Issue(s) This PR Fixes Fixes #5984 ### Problem / Evidence `GroupResetOffsetToolHandler.requireTimestamp` rejected only null, while `ResetConsumerOffsetDTO` (`@NotNull @Positive`, used with `@Valid`) rejects zero/negative - and the broker maps such a timestamp to the queue minimum, with only a WARNING in the plan: ``` GroupResetOffsetToolHandlerTest: applyShouldRejectANonPositiveTimestampTest Expecting code to raise a throwable ``` ### Root cause / Fix The positivity rule the REST contract enforces was never mirrored into the tool. Require a strictly positive value with the same message; the handler is the right boundary because the preview path uses the same helper, so no plan is built either. The published tool schema and the generated CLI catalog still describe the field without a minimum, so a client-side check is a follow-up (the server refuses the mutation either way). ### Priority and scoring **PRIORITY 55** - impact 26/40 (a destructive operation accepted from input the console refuses), blast radius 10/20 (callers that pass a placeholder), reproducibility 16/20 (pinned by the new test), maintenance value 3/20. **FIX_CONFIDENCE 80**. ### Tests `cd server && mvn -o -B -ntp test -Dtest='org.apache.rocketmq.studio.ops.ai.tool.**'` -> `Tests run: 177, Failures: 0, Errors: 0`; the new case (0 and -1) fails before the change and passes after it, asserting no broker call; `checkstyle:check` passes. ### Risk A caller that previously passed a non-positive placeholder now gets a 400 instead of a reset; the console and the REST endpoint already behaved that way. -- 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]
