iloveeyjafjalla opened a new issue, #6754: URL: https://github.com/apache/rocketmq-dashboard/issues/6754
### 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 (rmqctl/ with go build) ### Runtime Environment OS: Windows 11 24H2 (Git Bash); the same behaviour is observable on Linux and macOS browser: not applicable (CLI issue) ### Connected RocketMQ Cluster not applicable - the snippet is generated locally, no cluster is contacted ### Build Toolchain Go 1.27.1 (the version rmqctl/go.mod requires), built with "go build -o rmqctl.exe ." ### Describe the Bug "rmqctl mcp config" emits the MCP client snippet with the --command value copied verbatim. --command is documented as the executable path the client should start, so when it is a relative path (e.g. ./dist/rmqctl, the natural invocation when the binary is not on PATH) the snippet points at a location that only exists relative to the shell that generated it. Every MCP client launches the server from its own working directory, so the spawn fails and the tools silently never appear in the client - the failure mode #5916 names for a missing --instance-id. The same working-directory argument was already applied to the --config argument earlier today (#6460: "The MCP client may launch from a different working directory"), but the command path itself was left relative. ### Steps to Reproduce 1. Build the CLI: cd rmqctl && go build -o rmqctl.exe . 2. Run it with a relative command path: ./rmqctl.exe mcp config --command ./rmqctl.exe --instance-id local-broker 3. Read the "command" field of the emitted snippet and note that it is the relative string. ### What Did You Expect to See? The snippet's command to be usable from the client's own working directory - i.e. an absolute path when the supplied value names a file, while a bare name (the documented default "rmqctl") stays as it is because the client resolves that through PATH. ### What Did You See Instead? A relative path was emitted verbatim: BEFORE "command": "./rmqctl-after.exe" so a client starting the server from its own directory looks for the binary there, fails, and the tools never appear. With the shipped default the field is "rmqctl", which no one notices; with an explicit relative path the snippet is unusable. ### Additional Context Reproduced on a92c2314 with the binary built from that tree: $ ./rmqctl.exe mcp config --command ./rmqctl.exe --instance-id local-broker { "mcpServers": { "rocketmq-studio": { "args": ["mcp", "stdio", "--instance-id", "local-broker"], "command": "./rmqctl.exe" <- relative } } } $ rmqctl.exe mcp config --command ./rmqctl.exe --instance-id local-broker (same tree + the fix) { "mcpServers": { "rocketmq-studio": { "args": ["mcp", "stdio", "--instance-id", "local-broker"], "command": "C:\Users\...\rmqctl\rmqctl.exe" <- absolute } } } A bare name stays untouched: "mcp config --instance-id local-broker" still emits "command": "rmqctl", which is what the flag's documented default relies on. Related, not duplicates: #6460 made the --config argument absolute for the same working-directory reason (merged today), and #5916 handles the other way the snippet can fail to start (a missing --instance-id); neither resolves the command path. ### 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]
