davsclaus opened a new pull request, #29390: URL: https://github.com/apache/camel/pull/29390
## Description [CAMEL-26720](https://issues.apache.org/jira/browse/CAMEL-26720): the first part of S2-5 in the stage 2 order decided on [CAMEL-26607](https://issues.apache.org/jira/browse/CAMEL-26607?focusedCommentId=18140177&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-18140177). It checks a rule before it is added, so a person, or an AI that made the rule from a loose request, sees what the rule would do. **Stacked on #29389** (CAMEL-26719), which is stacked on #29388, #29387 and #29386. Retarget this PR to `main` once those have merged. ``` $ camel cmd chaos-add --dry-run --rule='endpoint=http:* in=orders error status=503' Would add: endpoint=http:* in=orders error status=503 fail every send to http:* in route orders with HTTP status 503 send http://inventory/stock in route orders (step callStock) (dry run: nothing was added) ``` ### camel-chaos - `ChaosManager.checkRules(String)` parses and checks rules as `addRules` does. A rule that is not valid is refused with the same reason, including the route check of `stall` and `lifecycle`. Nothing is added. - For each rule it returns: - the rule in plain words, at the hooks where it can fire; - those hooks; - the warnings; - `hits`: what the rule would hit now. - `ChaosTargets.hits` finds the hits: - the sends to a matching endpoint, with their route and step; - the sends known only when they send that may match (`toD` and the like); - the polls of a scheduled poll consumer; - the routes of a `route=` rule; - the steps of a `step=` rule. - All of these are narrowed by `in=`. Each list stops at 25, with `more` for the rest. Endpoint queries are left out, as they can hold secrets. - The send of the dead letter channel is not listed: it belongs to the error handler. A `when=` condition is only known per message. ### CLI connector, CLI, MCP and camel ask - The `chaos` action of the CLI connector has a `check` command. - `camel cmd chaos-add --dry-run` sends that command and prints the result. - The chaos tool group gets `camel_runtime_chaos_check` (MCP) and `chaos_check` (`camel ask`). Both are `readOnlyHint=true` and `destructiveHint=false`, so the `read-only` access level offers them, and `camel ask` does not ask before it runs one. - The check is left off the development MCP tools that `camel run --mcp` serves over HTTP. It is read-only, but the integration parses the rule, and `exception=` loads a class. Over HTTP, only the list and the report are offered, as before. ### Docs - `chaos.adoc` has a dry-run example, and its catalog copy is updated. - `camel-jbang-mcp.adoc` has a row for the new tool. - `camel-jbang-managing.adoc` and the tool table of the design doc are updated. - The `chaos-add` command page and the command metadata are regenerated, and the CLI help golden is updated. ## Tests - camel-chaos: 768 tests, all green. The new `ChaosCheckTest` covers each kind of hit, `in=`, `toD`, several rules, `when=`, and that a refused or checked rule adds nothing. - camel-cli-connector: `LocalCliConnectorChaosActionTest` (14) passes, with a check against a running context. - camel-jbang-core: `CamelChaosActionTest` (with the printed dry run), `ToolGroupsTest`, `ToolRegistryTest`, `AskToolsTest`, `JbangDevMcpServerTest` and `CliHelpGoldenTest` pass. - camel-jbang-mcp: all 541 tests pass, including `RuntimeToolsChaosTest` and `RuntimeToolsChaosSecurityTest`. - camel-jbang-plugin-tui: `AiPanelPromptBudgetTest` and the Chaos* tests (53) pass. I did not check this against a running integration: that needs the core jars of #29386. _Claude Code on behalf of Claus Ibsen_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- 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]
