davsclaus opened a new pull request, #26602: URL: https://github.com/apache/camel/pull/26602
Fixes https://issues.apache.org/jira/browse/CAMEL-24818 With an `onFallback`, the fallback path of `ResilienceProcessor` and `FaultToleranceProcessor` set the same exchange properties for every cause (`FromFallback=true`, `ShortCircuited=true`), and `CamelCircuitBreakerResponseRejected` was only set when there was no fallback. A fallback therefore could not tell a call that was made and failed from a call the open breaker never attempted, other than by inspecting the exception class. - Both processors now set `CamelCircuitBreakerResponseRejected` in the fallback path: `true` for `CallNotPermittedException` / `BulkheadFullException` (Resilience4j) and `CircuitBreakerOpenException` / `BulkheadException` (fault tolerance), `false` otherwise. - `CamelCircuitBreakerResponseShortCircuited` keeps its behaviour for compatibility; its description and the rejected description are corrected in `CircuitBreakerConstants`, with the model and catalog regenerated. - The circuit breaker EIP page gets a short section on how to read the properties inside a fallback, with a YAML example. - One test per processor: two failures open the breaker, the third call is rejected; the first exchange has `Rejected=false` with the service exception caught, the third `Rejected=true` with the breaker exception caught. Full test suites of camel-resilience4j (69) and camel-microprofile-fault-tolerance (28) pass locally. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01Bp3538HRBPMQkb5ta9xRaj -- 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]
