Frun1na opened a new issue, #5653: URL: https://github.com/apache/rocketmq-dashboard/issues/5653
### Before Creating the Bug Report - [x] I have searched the [open issues](https://github.com/apache/rocketmq-dashboard/issues) of this repository and believe that this is not a duplicate. - [x] This is a defect in RocketMQ Studio, not a usage question and not a defect in another Apache RocketMQ repository. - [x] I can reproduce this on the current `master` branch, or I have stated the exact version I am running below. ### Studio Version branch: `rocketmq-studio` git commit id: `6a68042f` deployed as: built from source (`go build .` in `rmqctl/`) ### Runtime Environment OS: Ubuntu 22.04 (WSL2) MySQL: not applicable — the defect is in the CLI's handling of its own dry-run handshake browser: not applicable ### Connected RocketMQ Cluster RocketMQ version: not applicable — the defect is in the CLI-side argument assembly access mode: not applicable deployment: not applicable ### Describe the Bug The two-phase handshake for L2/L3 tools is documented as: run `--dry-run`, then replay the mutation with the returned `--confirm-token`. For a tool with an `x-client-default: NOW` field that replay can never succeed: - the server signs the previewed business input into the token — `ToolTokenService.signingPayload` → `canonicalInput(context.businessInput())`, and `ToolExecutionContext.businessInput()` removes only `break_glass`, `confirm_token`, `dry_run` and `reason` from the input, so `timestamp` is part of the signature; - the CLI fills that field on **every** invocation — `cmd/catalog.go`, `applyClientDefaults` (called from `runTool`) uses `nowMillis()`, and its own flag help says "rmqctl fills in the current time when the flag is not provided"; - so the replay carries a fresh timestamp, the signature check fails, and the caller gets `CONFIRMATION_TOKEN_INVALID` — whose hint is "Run with --dry-run again and retry with its fresh token without changing the operation input", which is exactly what the caller did. Only `rmq.group.reset_offset` has such a field today (`group.yaml`: `timestamp`, `x-client-default: NOW`), and the flag is schema-required, so the caller cannot simply omit it. Passing the timestamp printed in the preview plan does make the same token work. ### Steps to Reproduce ``` # 1. preview, note the token and the plan's timestamp $ rmqctl group reset-offset --instance-id <id> --group-name <g> --topic-name <t> --dry-run -o json # 2. replay the same command with the token, nothing else changed $ rmqctl group reset-offset --instance-id <id> --group-name <g> --topic-name <t> \ --confirm-token <token> --yes error [INVALID_ARGUMENT]: Tool confirm_token is invalid, expired, or does not match the tool, caller, Instance or preview input. hint: Run with --dry-run again and retry with its fresh token without changing the operation input. # 3. the token is fine — pinning the value the preview signed makes it work $ rmqctl group reset-offset ... --timestamp <plan.after.timestamp> --confirm-token <token> --yes ``` The CLI-level part is pinned by a test: `TestConfirmTokenReplayWithAutoFilledTimestampIsRefused` asserts the current behaviour (the tool call is sent with the fresh timestamp instead of being refused). ### What Did You Expect to See? The CLI should not send a call it can already know the server will reject. Either replay the exact previewed input, or refuse the replay up front with a message naming the flag to pin — the hint the caller gets today points at a path that cannot work. ### What Did You See Instead? A `CONFIRMATION_TOKEN_INVALID` failure on an unchanged command, with the blame pointing at "changing the operation input" that the caller did not change. ### Additional Context - the documented single-call alternative is unaffected: without `--confirm-token`, the CLI transparently runs the preview and the mutation with the same in-memory arguments, so the timestamps agree. - `rmq.group.reset_offset` is the only tool with `x-client-default: NOW` in the catalog today. ### Are You Willing to Submit a Pull Request? - [x] Yes, I am willing to submit a pull request. -- 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]
