davsclaus opened a new pull request, #29363: URL: https://github.com/apache/camel/pull/29363
[CAMEL-26701](https://issues.apache.org/jira/browse/CAMEL-26701): two bugs from a hands-on round of the chaos screen, using a demo shop with a payment call behind a resilience4j circuit breaker that has a fallback. ### 1. A fault caught by a circuit breaker fallback counted as failed The rule on the payment call showed `156 failed`, while the payment route had 0 failed and every order shipped through the fallback. The circuit breaker runs its steps on a correlated copy of the exchange, with its own unit of work (`ResilienceProcessor.processTask`). Chaos faulted the copy and counted the effect when the copy's unit of work was done, so as failed. The exchange itself was never counted. Now the faults of a copy made inside a try block (a correlated copy with `TRY_ROUTE_BLOCK`, which the circuit breaker sets) count when the exchange they are a copy of is done, with its outcome: - `completed` when the fallback took over; - `handled` by the dead letter channel; - `recovered` when a redelivery succeeded; - `failed` otherwise. A message that the circuit breaker runs again at a redelivery (a new copy each time) counts once (`Faults.merge`). The exchange is not touched from the copy's thread, as a circuit breaker with a timeout runs its fallback on the caller while the copy may still run. The faults wait under the exchange id in `ChaosManager` until its `ExchangeCompletedEvent` or `ExchangeFailedEvent`. The notifier listens for completed events only while something waits (`isIgnoreExchangeCompletedEvent`), so it costs nothing otherwise. The map is bounded. A wait with no event within a minute counts with how the copy was done: for example a wire tap inside a `doTry`, whose exchange may be done before its copy. The inflight repository is not used to find the exchange, as browsing it is off by default. Without a fallback, a circuit breaker's failure is not redelivered by the error handler of its own route. So the redelivery test puts the circuit breaker in a route called with `direct:`, from a route with a dead letter channel. Known limit, in the javadoc: a splitter inside a `doTry` also makes correlated copies in a try block, so a fault in a split part counts with the parent's outcome (completed when the `doCatch` caught it). ### 2. A recovered fault marked a later, real error `CamelChaosRule` stayed on an exchange after a redelivery recovered its fault. So a later failure that chaos did not make showed the mark of the old rule on the Errors tab: in the demo, the open circuit breaker's `CallNotPermittedException` was marked `🎲r1`, the rule on the stock call. Now: - the property is removed when the error handler redelivers the exchange, and a fault at the redelivery sets it again; - the Errors tab trusts an error's properties when it has them (`ChaosMarks.ruleOf`), and uses the recent faults of the report only when an error has no properties. ### Also - camel-resilience4j is now a test dependency of camel-chaos. - `chaos.adoc` describes both; the catalog copy is updated. ### Tests - `ChaosCircuitBreakerEffectTest`: the fallback, the dead letter channel without a fallback (one message over three copies), recovered by a redelivery, and no mark on a later failure. - All 656 camel-chaos tests pass, and the TUI chaos tests pass (`ChaosMarksTest` gets a case for an error with properties and no mark). _Claude Code on behalf of Claus Ibsen_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_012nJsFsjqqFiwroeHRWaKbS -- 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]
