davsclaus opened a new pull request, #29311: URL: https://github.com/apache/camel/pull/29311
## CAMEL-26676: camel-chaos - feedback while adding rules > Stacked on #29309 (CAMEL-26675). Review only the last commit; it targets that branch until #29309 is merged. The third follow-up from the hands-on round of camel-chaos stage 1 ([CAMEL-26667](https://issues.apache.org/jira/browse/CAMEL-26667)). In that round, typo'd rules were accepted silently and fired 0 times, a rule skipped 79 of 79 times didn't say why, and adding two rules that must both be in place needed the right order. | Before | Now | |---|---| | `endpoint=htp://localhost:8765/stock*`, `step=callStok` or `expect=shiping:10` were accepted with only an id (`{"id":"r3"}`); one WARN in the application log for the expectation only | A rule that matches nothing in the context now is added with a warning that names some of what is there: `endpoint=htp://... matches no endpoint of the context now, so the rule fires 0 times ...; the endpoints are: direct://inventory, file://inbox, http://localhost:8765/stock, ...`. It is logged, returned by `ChaosManager.checkRule(id)`, printed by `chaos-add`/`chaos-change`, and returned by the MCP and `camel ask` tools (`warnings`), so an agent can fix the typo with a change. It also covers `at=poll` with no scheduled poll consumer, and is checked for `camel.chaos.rules` once the context has started. It is a warning, not an error: a `toD` creates its endpoints when it sends | | Each `chaos-add` is one CLI run (about a second), so two rules that must both be in place (an `at=dlq` rule and the rule that sends a message there) had to be added in the right order | `chaos-add --rule=... --rule=...`, `ChaosManager.addRules("a; b")` and the add tool (`;`-separated) add rules together, all or none | | `route=shipping corrupt mode=charset` was skipped 79/79 times with no reason anywhere | Skips are counted per reason (`skippedReasons` in JSON, in the text report, and in the NOTE column), e.g. `a stream body (charset changes a text body; mode=truncate changes a stream)` | | `camel get chaos` showed a stall as `active 1 1 0`, and printed nothing with no rules or without camel-chaos | A NOTE column (only when a rule has something to say): `route poller down, back in 12s`, `skipped 79: a stream body ...`. With nothing to show it says so on stderr (`no chaos rules`, `No running integration has camel-chaos`) | Endpoints in a warning are named as Camel shows them elsewhere, without their query (which can hold secrets) and sanitized. Not done from the JIRA: listing only the hooks that apply to the matched endpoints (a `direct:` rule lists `poll`). The warning covers the useful case: `at=poll` for endpoints without a scheduled poll consumer. ### Tests - `ChaosRuleFeedbackTest` (new): no warning for rules that find something, plus endpoint, step, route, expectation and `at=poll` warnings, a changed rule, `addRules` (together, quote-aware `;`, all or none) and skip reasons. - Also tested: the connector (multi-add and warnings) and `ListChaosTest` (NOTE column, no rules, no camel-chaos). - All 547 tests of camel-chaos pass, and so do the chaos tests of camel-cli-connector, camel-jbang-core and camel-jbang-mcp. - Live check with `camel run --chaos` and the Camel CLI: the scripted hands-on rerun passes 30 of 33 checks against the jars of this branch, including the new warnings, multi-add, skip reason and no-rules scenarios. The 3 that fail are the rule rejections of #29303, which is not in this stack. ### Docs `chaos.adoc` (and the catalog copy), the MCP tools table, and the generated `chaos-add` command doc and metadata. _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]
