davsclaus opened a new pull request, #29387: URL: https://github.com/apache/camel/pull/29387
Stacked on #29386 (CAMEL-26607, more than one StepHook and SendHook, and the `duplicate` fault). Review that one first; this PR targets its branch. ## What Step 2 of the stage 2 order decided on CAMEL-26607: S2-4, P-2, and `ChaosRule.describe()`. **A rule in plain words.** `ChaosRule.describe()` says what a rule does, for every target, hook and fault: - `endpoint=kafka:orders* error rate=0.1` → "fail 10% of the sends to kafka:orders*" - `endpoint=file:inbox* drop at=poll rate=every:10 until=100` → "drop 1 in 10 polls of file:inbox*, for the next 100 polls" - `component=kafka duplicate rate=0.05 from=+30s` → "duplicate 5% of the sends to the kafka endpoints, starting after 30 seconds" - `step=enrich* error exception=java.sql.SQLException expect=orders:handled<=0` → "fail every run of step enrich* with SQLException; expects no exchanges handled by the error handler in route orders" It shows in the chaos dev console and report (`description` per rule), in the answer of the chaos action of the CLI connector, in the confirmation of `chaos-add` and `chaos-change`, in `camel get chaos` (also `--json`), in the MCP chaos add and list tools and `camel ask`, and in the notification of the chaos screen when a rule is added or changed. `in=` (S2-2) and `when=` (S2-3) will extend it. **The integration name is optional (S2-4).** Without a name or pid, `chaos-add`, `chaos-change` and `chaos-remove` act on the only integration that runs, or else the only one with chaos switched on. Otherwise they fail with exit code 2 and the list: ``` 3 Camel integrations are running and 2 have chaos switched on: billing (pid 2001, chaos on), shop (pid 2002, chaos off), orders (pid 12345, chaos on). Give the name or pid of one. ``` Add and change never mean all of them. `chaos-clear` keeps its default `*`. The MCP chaos tools and the chaos tools of `camel ask` pick the integration the same way (`ProcessFinder.requireOneForChaos`). **The hooks of a rule are the ones that can fire (P-2).** The `hooks` of a rule in the list and the report used to show `poll` and `send` also where they cannot fire. Now: - `poll` shows only when a route that matches consumes the endpoint with a scheduled poll consumer. - `send` and `reply` show only when something sends to a matching endpoint: a `to`, a dynamic send whose URI may match (`toD`, `wireTap`, `enrich`, `recipientList`, `routingSlip`, `dynamicRouter`, by the static part of the URI), or an endpoint of the context that a template sent to. - A hook where the rule already fired always shows. The rule still fires at all its hooks, and `fired` keeps them all. A send from a ProducerTemplate to the consumer endpoint of a route (such as `camel cmd send` to `direct:start`) cannot be known in advance, so `send` shows there once the rule has fired. ## Docs The chaos page (a rule in plain words, the hooks, the optional name) and its catalog copy, the chaos design, and the managing page of the CLI. The help of the commands and the CLI goldens. The chaos dev console JSON and its catalog copy are regenerated, and `dev-consoles-openapi.json` is updated to match. Only the new `chaos-add`, `chaos-change` and `chaos-remove` cases were added to `cli-parse.txt`. Regenerating it would also bring in unrelated cases that are out of date on main (`chaos-clear`, `get chaos`, `dev --chaos`), which belongs in a fix of its own. ## Tests - `ChaosRuleDescribeTest` (37): every fault, target and hook, rates, times, expectations, and the examples of the docs. - `ChaosHooksTest` (5): poll only for a scheduled poll consumer, send for a `to`, a `toD` and a template. - `CamelChaosActionTest`: the only one running, the only one with chaos on, several with chaos on, none with chaos on, nothing running, and the plain words. - `RuntimeToolsChaosTest`, `LocalCliConnectorChaosActionTest`, `ListChaosTest` and `ChaosControlTest`. - Locally, these suites pass in full: camel-chaos (713), camel-cli-connector (92), camel-jbang-mcp (541) and the TUI (2339). camel-jbang-core ran its affected classes (144), including both CLI goldens. JIRA: https://issues.apache.org/jira/browse/CAMEL-26717 _Claude Code on behalf of Claus Ibsen_ -- 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]
