davsclaus opened a new pull request, #27931: URL: https://github.com/apache/camel/pull/27931
Step 10 of [CAMEL-25388](https://issues.apache.org/jira/browse/CAMEL-25388): an AI agent that drives the Camel CLI, through `camel ask`, `camel mcp` or the monitor's MCP server, learns that something failed from the exit code or `isError`, not by reading prose. ### CliRunner (one way to run a command in this JVM) - `CliRunner.run(args[, timeout])` returns `CliResult(exitCode, stdout, stderr, elapsedMs, timedOut)`: the printer of the CLI and picocli's out and err are captured apart, and restored afterwards. A command that does not finish in time is interrupted and gets `124`. - One lock (`CliRunner.LOCK`, the `CamelJBangMain.class` monitor the runners already used): `camel ask`, the AI panel of the monitor, and now also each command of the camel shell (`CamelShellCommandRegistry` wraps its commands), as they share the printer of the CLI. - The AI panel's executor uses it, so a command's help and usage errors are captured too (picocli out went to the real stdout under the monitor). ### camel ask `cli_exec` - Returns `{"exitCode", "stdout", "stderr", "elapsedMs", "timedOut"}` with a 60 second timeout. Before, the exit code was dropped whenever the command printed something. - Refuses a command that runs until it is stopped, with the form that returns: `run`/`dev` without `--background` or a `--max-*` limit, `infra run` without `--background`, `log`/`infra log` (and `trace`/`cmd receive --action=dump`) without `--follow=false` or `--duration`, `--watch` without `--duration`, `debug`, `shell`, `tui`, `nano`, `edit`, `ask`, `hawtio`; `export --clean-dir` needs `--yes` (its prompt cannot be answered there). A command that changes something is still asked first (CAMEL-25676), and without a terminal it needs `camel ask --yes`. ### Tool failures are errors - `camel_run` with `status: failed` throws, so MCP answers `isError` (the JSON with the exit code and output is the error text). - `IntegrationLauncher`: a restart that fails or cannot start, and `kill` of a process that is gone, throw. - `ToolContext.executeAction` throws when the integration answers with an error (the 4.24 connector answers failures since CAMEL-25390) or does not answer; before, the timeout text came back as a normal answer. - New `ToolContext.sendAction` (and `ActionClient.send(pid, ...)`) for actions without a result: route stop/start/suspend/resume and `camel_control stop-routes/start-routes/reset-stats/reload` wait for the confirmation, and an integration before 4.24 takes the action unconfirmed, as `camel cmd` does. - `camel_runtime_ai_trace` no longer turns a failed query into "no AI components". - The monitor: `executeShared` and the summary write rethrow tool errors, so its MCP server sets `isError`; only an unknown tool is "Unknown tool" (any `IllegalArgumentException` inside a tool was reported as an unknown tool, also in the AI panel). A failed `tui_run_example` is a tool error. ### The monitor's launches - A restarted Camel Main integration is watched like a launch: a failed restart shows why, and quitting the monitor stops it (the process was dropped, and its log went to the public temp dir). `camel_control restart` waits up to 30 seconds for the outcome; a failed start is a tool error with the end of the log. - A launch counts as started when the status file of the integration, or of a process it started (the app of a Maven launch), says Camel has started. The log is still read for a start that fails while the JVM lives on (Spring Boot `APPLICATION FAILED TO START`, a Maven build failure, Quarkus dev mode) and for an app without the CLI connector, which writes no status file, so log scraping is not removed entirely. ### External commands - `docker info` / `podman info` (`camel doctor`, the monitor's doctor and launches) and the Ollama monitor's `ps`/`nvidia-smi`/`ioreg` read the output to the end and then waited, so the timeout never applied (`camel doctor` had none). `ExternalCommand` discards the output or reads it while the command runs, and destroys a command that does not finish in time. ### Docs - 4.24 upgrade guide: "the AI tools report failures as errors". - `camel-jbang-ai.adoc`: what the model gets from a `camel` command, and which commands it does not run. ### Tests - `CliRunnerTest`: output and exit code, not found, picocli usage error and help, a command interrupted after the timeout (124), the JSON. - `AskToolsTest`: the blocking commands and their hints, and the refusal through `cli_exec`. - `ExternalCommandTest`: exit codes, a hanging command destroyed in time, output larger than a pipe holds. - `TuiMcpServerToolErrorTest`: a tool error and an unknown tool answer `isError`, a normal answer does not. - `LaunchManagerOutcomeTest`: started from the status file, failed from the exit code with the log in the restart error, the phases of a started Camel. - `TuiToolRegistryEvalExpressionTest` expects the tool error instead of the `Error:` text. - `mvn test` of camel-jbang-core, camel-jbang-plugin-tui and camel-jbang-mcp: all tests pass. _Claude Code on behalf of davsclaus_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01DDRLJAyf8cDXSg8iX785My -- 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]
