The GitHub Actions job "CI" on rocketmq-dashboard.git/fix/reset-offset-timestamp has failed. Run started by GitHub user unbridled-41 (triggered by unbridled-41).
Head commit for run: 825a2be9053614399b1931639f68b599f71607cd / unbridled-41 <[email protected]> fix(ai): reject a non-positive reset timestamp instead of rewinding every queue `rmq.group.reset_offset` accepted any non-null timestamp: if (input.timestamp() == null) { throw new BusinessException(400, "timestamp is required"); } return input.timestamp(); while the console's own contract for the same parameter is `@NotNull @Positive` (ResetConsumerOffsetDTO, used with @Valid by ConsumerGroupController). The broker resolves a timestamp at or before the first stored message to the queue's minimum offset, so `{"timestamp":0}` - or any negative placeholder a caller passes - is a legal, *applied* L2 mutation through POST /api/ai/tools/rmq.group.reset_offset, POST /api/mcp/tools/call and `rmqctl group reset-offset --timestamp=0`: every queue of the topic rewound to the beginning, i.e. a mass replay of already-consumed messages for that group. The preview only rated that target WARNING, so the allowReset gate did not fire and a confirm token was issued. The identical input is a 400 on /api/groups/reset-offset. Require the value to be strictly positive, with the message the REST contract uses. The published tool schema and the generated CLI catalog still describe the field without a minimum, so a CLI-side check is a follow-up (the server now refuses the mutation either way). Tests (server/): mvn -o -B -ntp test -Dtest='org.apache.rocketmq.studio.ops.ai.tool.**' -> Tests run: 177, Failures: 0, Errors: 0. - new applyShouldRejectANonPositiveTimestampTest (0 and -1) fails before this change ("Expecting code to raise a throwable") and passes after it, asserting no broker call happens. - checkstyle passes. Report URL: https://github.com/apache/rocketmq-dashboard/actions/runs/37991147949 With regards, GitHub Actions via GitBox
