pilichoumao opened a new issue, #6020: URL: https://github.com/apache/rocketmq-dashboard/issues/6020
### Problem On `rocketmq-studio` at `7e7aa344`, confirmation authenticates the tool, caller, instance and request input, but not the Topic configuration shown by dry-run. If a second operator changes that configuration after preview, the first operator can still execute with the original token. `TopicUpdateToolHandler` reads the new state and merges the original partial update into it without requesting a fresh review. A regression using the real Topic update handler and mutation filter reproduces this: preview with 8 read queues, change them to 16, then apply the original write-queue update. The current branch performs the write instead of reporting a conflict. ### Proposed narrow scope Start with `rmq.topic.update` only. Bind a signed digest of its stable before/after configuration to the confirmation token. Keep summary, impact text, warnings and dynamic counters outside the digest. Authenticate the request before reading a new preview, then compare the current stable projection before entering the mutation chain. Return HTTP 409 / `CONFLICT` with a fresh dry-run hint if it changed; malformed, expired or request-mismatched tokens remain invalid arguments. Keep other tools on their existing behavior until each has an explicit stable projection. Existing unbound Topic update tokens require a fresh preview after deployment. No new configuration or request fields are needed; clients continue treating tokens as opaque. ### Coordination and limits This is complementary to #5452 (single-use confirmation tokens), not a replacement. A draft implementation can demonstrate the state binding independently of that PR; the token representation and final verification/consumption order must be reconciled before it is ready to merge. The draft must not duplicate the single-use implementation. This detects changes between dry-run and the execution preview. It does not provide an atomic compare-and-set with Broker writes and cannot prevent a change after the final comparison. Full Broker-level concurrency control and extending the mechanism to all mutation tools are outside this proposal. Would maintainers accept this narrow Topic-first direction and the upgrade behavior before it is made ready for review? -- 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]
