unbridled-41 opened a new issue, #5984:
URL: https://github.com/apache/rocketmq-dashboard/issues/5984
### Studio Version
branch: `rocketmq-studio` @ `7e7aa344`
### Runtime Environment
Backend tests: `cd server && mvn -o -B -ntp test
-Dtest='GroupResetOffsetToolHandlerTest'`.
### Describe the Bug
The AI/MCP tool `rmq.group.reset_offset` rejects only a null timestamp,
while the console's contract for the same parameter is `@NotNull @Positive`.
The broker resolves a timestamp at or before the first stored message to the
queue's minimum offset, so `{"timestamp":0}` (or a negative placeholder) is a
legal **applied** L2 mutation through `POST
/api/ai/tools/rmq.group.reset_offset/execute`, `POST /api/mcp/tools/call` and
`rmqctl group reset-offset --timestamp=0`: every queue of the topic rewound,
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`.
### Steps to Reproduce
Call the tool (or the CLI) with `timestamp: 0` for a group with consumed
offsets; the plan is issued and can be applied.
### What Did You Expect to See?
A 400, as the REST endpoint answers.
### What Did You See Instead?
An executable reset to the minimum offset.
### Impact
A destructive operation executed from an input the console refuses.
### Acceptance Criteria
The handler rejects a non-positive timestamp with the REST contract's
message before any broker call, with a regression test.
**Corresponding PR:** #ISSUEPR#
--
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]
