iloveeyjafjalla opened a new issue, #6844: URL: https://github.com/apache/rocketmq-dashboard/issues/6844
### 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: a92c2314 fix(settings): resolve data source type aliases to their own backend probe (#6489) deployed as: built from source (server/ + rmqctl/ with go build) ### Runtime Environment OS: Windows 11 24H2 (Git Bash); the schema/service mismatch is platform independent browser: not applicable ### Connected RocketMQ Cluster any instance works for the repro; it was reproduced against a local 5.3.2 broker registered as local-broker ### Build Toolchain Go 1.27.1 (rmqctl/go.mod), JDK 21, Maven 3.9.9 (server/) ### Describe the Bug The three paged tools - rmq.acl.list, rmq.audit.list and rmq.message.query_dlq - pass pageSize to services that reject anything above 100 with a 400 ("pageSize must be between 1 and 100"), but their published inputSchema declares only minimum: 1. The tool schema is the contract every caller reads: rmqctl's generated catalog is built from it, and ToolSchemaValidator checks agent calls against it before the handler runs. A caller that follows the contract can therefore build a call that the service then refuses, and the CLI never names the ceiling it enforces: --page-size help says "(minimum: 1)" and nothing about an upper bound. Two consequences: - rmqctl: "rmqctl audit list --page-size 200" is accepted client-side, sent, and fails at execution with TOOL_EXECUTION_FAILED carrying the service's message, instead of being rejected up front as INVALID_ARGUMENT like every other declared bound (minimum, enum, minLength are all enforced client-side). - MCP/agent callers: a schema-valid tool call with pageSize 101 passes validation and only fails in the service. ### Steps to Reproduce 1. Read the declaration: server/src/main/resources/tool-catalog/tools/audit.yaml, lines around the page object - page.pageSize declares type: integer and minimum: 1, with no maximum. 2. Read the bound the service enforces: GET /api/audit-logs?pageSize=200 -> 400 {"code":400,"message":"pageSize must be between 1 and 100"} (the same bound is in AclService for rmq.acl.list and the DLQ service for rmq.message.query_dlq). 3. Optional, the user-facing symptom: with an instance whose MCP credential is configured, run "rmqctl audit list --page-size 200" and observe TOOL_EXECUTION_FAILED with the service message instead of a client-side INVALID_ARGUMENT. ### What Did You Expect to See? The contract to state the bound it enforces, so a follow-the-schema caller cannot build a call the service rejects, and so "rmqctl <tool> --help" names both ends of the range the way it already names the minimum. ### What Did You See Instead? - The schemas declare only minimum: 1 for page.pageSize (audit.yaml, acl.yaml, message.yaml). - GET /api/audit-logs?pageSize=200 answers 400 "pageSize must be between 1 and 100"; pageSize=100 answers 200. - rmqctl accepts --page-size 200 up to execution (its usage line reads "page size (minimum: 1)") and then surfaces the service's failure as TOOL_EXECUTION_FAILED. ### Additional Context Reproduced on a92c2314: - the bound is real and live: GET /api/audit-logs?pageSize=200 -> 400 "pageSize must be between 1 and 100"; pageSize=100 -> 200. - the same three tools' input schemas carry no maximum, while other bounds are declared (107 minLength and 22 enum entries across the catalog). - the CLI's own behavior shows the asymmetry: "rmqctl audit list --page-size 0" is refused client-side with INVALID_ARGUMENT ("must be at least 1") while --page-size 200 was only refused by the service. Note when fixing: the tool schema validator (ToolSchemaValidator) consumes the same inputSchema, so declaring the ceiling also makes agent calls fail fast with 400 before the handler runs - that is the intended direction, not a regression. ### 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]
