Croway opened a new pull request, #27958: URL: https://github.com/apache/camel/pull/27958
Section A of [CAMEL-25642](https://issues.apache.org/jira/browse/CAMEL-25642): the runtime tools of camel-jbang-mcp that were wired to the wrong keys, tools or protocol. Sections B (migration and dependency data) and C (OpenAPI scaffold) are separate PRs. ### Changes - **`camel_runtime_receive`** started a permanent consumer through the receive dev console, stole messages from the routes and answered only `{enabled, endpoints}`. It is now one call: enable the console for the endpoint, poll the `{pid}-receive.json` file the CLI connector appends to (the same file `camel receive` reads) for up to `timeoutSeconds` (default 10, at most 60), return what arrived, and disable the console in a `finally`. It is `destructiveHint=true`, refuses to run while `camel receive` is active on the process (disabling would stop that consumer too) and reports an endpoint nothing matches. `RuntimeService` gains `receiveFileSize` and `readReceivedMessages`. - **`routeId` was ignored** by `camel_runtime_route_dump`, `route_structure`, `route_analysis` and the `routeFilter` of `ai_trace`: the registry sent the pattern as `id`, `LocalCliConnector` reads `filter` (as `CamelRouteDumpAction` sends it). Fixed in the registry; `get_eip_stats` and `detect_config_drift` send `filter=*`; `brief` is passed to route_structure (the connector forwards it). `limit` is not added: the connector does not forward it for these actions. - **Prompts**: `camel_diagnose_route` and `camel_optimize_route` named tools that do not exist (`get_context`, `get_routes`, `get_top_processors`, ...). Rewritten with the MCP names (`camel_runtime_context`, `camel_runtime_top`, ...). `PromptDefinitionsTest#everyToolAPromptNamesExists` checks every backticked tool name of every prompt is a listed tool; the `@Tool` scan moved to a shared test helper `McpToolClasses`, used by `McpSecuredToolClassesTest` too. - **`camel_runtime_ai_trace`**: `nameOrPid` is optional like the other runtime tools. Rebased on main after CAMEL-25398 (#27931), which already turns a `ToolExecutionException` of the registry queries into an error; this PR adds the timeout-text detection (`RuntimeHelper.TIMEOUT_PREFIX`, `RuntimeTools.failOnTimeout`) so every registry-backed runtime tool reports "Timeout waiting for response" as an error instead of a success answer. - **Smaller**: `camel_runtime_http_request` passes the `timeoutSeconds` the registry declares; `camel_runtime_memory_leak` defaults to `single` (start returns at once, 60 s recording, matching the argument text), `dual` (about 90 s, blocking) is opt-in and documented, a `compare` command gives a trend without blocking, `duration` and `mode` are validated and the dual wait sleeps by the console's `remainingMs`; `camel_runtime_history` no longer claims history is "always captured" (it needs message history on and the tracer enabled or on standby, which the dev profile of `camel run` sets; the description names the keys for other setups). - **Hints**: `send_message` is destructive in the registry too (it keeps `core(true)` from main); `route_control` stays destructive for all commands, with a comment (an MCP hint is per tool; stop and suspend take the consumer offline); new read-only `camel_runtime_trace_dump` so read-only clients can dump traces; the heap dump name is refused when it contains a path separator or `..` and the MCP tool delegates to the registry. - **Docs**: tool rows in `camel-jbang-mcp.adoc`; upgrade guide 4.24 section "runtime tools that changed behaviour" (receive, memory_leak default, routeId filtering, timeouts as errors). ### Tests - New `ToolRegistryRuntimeActionsTest` (camel-jbang-core, 5 tests, records the requests through a fake `ToolContext`) and `RuntimeToolsWiringTest` (camel-jbang-mcp, 10 tests, recording `RuntimeService` plus a temp-home test for reading the receive file); `RuntimeToolsTest` adapted to the http_request argument. - After the rebase: `mvnd -P apache-snapshots test -pl dsl/camel-jbang/camel-jbang-core,dsl/camel-jbang/camel-jbang-mcp -Dtest='ToolRegistry*Test,RuntimeHelperTest,org.apache.camel.dsl.jbang.core.commands.mcp.**.*Test'`: camel-jbang-mcp 479 tests, 0 failures; the core tests pass. - Not verified against a running integration: the receive flow follows the protocol of `ReceiveDevConsole`, `LocalCliConnector.doActionReceiveTask` and `FileCliConnectorTransport` as read from the code. Not in this PR: `limit` for route_dump/route_structure (needs a camel-cli-connector change), `camel_runtime_trace_dump` in the TUI tool groups, the registry `summary` argument of `history`. _Claude Code on behalf of Croway_ -- 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]
