davsclaus opened a new pull request, #29309: URL: https://github.com/apache/camel/pull/29309
## CAMEL-26675: camel-chaos - report accuracy The second follow-up from the hands-on round of camel-chaos stage 1 ([CAMEL-26667](https://issues.apache.org/jira/browse/CAMEL-26667)). In each of these cases the report told a developer something other than what happened: | Before | Now | |---|---| | `endpoint=*` or `component=seda error` also failed the send of the dead letter channel. With `deadLetterHandleNewException` (the default) the message was gone and counted as *handled*, and the report said `lost: 0` (seen live: `orders handled 11`, `dlq completed 10`) | The send of the dead letter channel is a new hook, `dlq`, which a rule reaches only with `at=dlq`. When such a rule fails or drops that send and the dead letter channel then handles the exchange, the message counts as lost (`lostAtDlq` per rule), and the verdict is FAIL with the reason | | A route counted an exchange once per *pass*. A `direct` route called in a loop, or called again by a redelivery of the calling route, counted it several times in completed/failed and in its expectations, and a `route=` corrupt rule fired once per pass | Counted once per exchange and route, with the outcome of the last pass (a failed pass and then a completed one count as one completed exchange). Expectations count the exchange the first time it completes, and entry faults are asked once per exchange | | An expectation of a removed or changed rule, or of a stopped context, stayed *pending for good*, so the report could never be final again (an MCP agent waiting for `final` never stops) | The expectation is `cancelled`: neither met nor unmet, and it does not keep the report pending | | `chaos-clear` kept the old verdict, `lost` and history until a restart | `camel cmd chaos-clear --reset` (also `reset=true` on the MCP and `camel ask` tool, and `ChaosManager.reset()`) starts a new report. Rule ids go on from the last one | | Rules of `camel.chaos.rules` started their clock when the context initialized, so a slow startup shortened their `until`/`within` | Their clock starts when the context has started | | The JSON report listed the versions of one id as 3, 1, 2 | Rules are in the order of their ids, and the versions of an id from the latest | ### How - The per-exchange state (`ChaosExchangeState`) is a `SafeCopyProperty` of the exchange. It is internal (not one of the exchange properties), and a copy (wire tap, split, seda) starts with a fresh one, so copies count on their own as before. - The event notifier marks the exchange between `ExchangeFailureHandlingEvent` and `ExchangeFailureHandledEvent` of the dead letter channel, which camel-core fires around that send. So it now also listens to the exchange failed events, while there are rules. - After a reset, an exchange still in flight cannot subtract from the new counts: the route state remembers which counts it was counted in. ### Tests - New tests for: the loop and redelivery counting, entry faults once per exchange, `at=dlq` (lost, delay delivers, the loss stays in the verdict after the rule leaves the history), cancelled expectations, reset, and the startup clock (`ChaosStartupClockTest`, on a virtual clock). - Updated the tests that pinned the old behaviour: pending for good, DLC send hit by `mock:*`, version order. - All 539 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`, the Camel CLI and the report: a scripted rerun of the hands-on scenarios passes 18 of 21 checks against the jars of this branch. The 3 that fail are the rule rejections of #29303, which is not in this branch. Main fails 9 of the same 21, among them `handled != DLQ deliveries` with `lost: 0`. ### Docs `chaos.adoc` (and its catalog copy) covers the `dlq` hook, counting per exchange, cancelled expectations, `--reset` and the startup clock. Also updated: the MCP tools table, and the generated `chaos-clear` command doc and metadata. Camel 4.24.0 is not released yet, so there is no upgrade guide entry. _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]
