davsclaus opened a new pull request, #24797: URL: https://github.com/apache/camel/pull/24797
## Summary _Claude Code on behalf of davsclaus_ Both `ResilienceProcessor` and `FaultToleranceProcessor` have a race condition where the worker thread writes results back to the original exchange after a timeout has triggered fallback processing on the caller thread. This can: - Overwrite the fallback result with the late worker result - Reinstate an exception after the fallback cleared it - Corrupt the exchange through non-atomic interleaving of `ExchangeHelper.copyResults` **Fix:** Add a shared `AtomicBoolean` guard between the worker task and the fallback task. The worker uses `compareAndSet(false, true)` before writing back — if the fallback already claimed the exchange, the write-back is skipped. The fallback sets the guard to `true` before touching the exchange. Both the normal result path and the exception catch path in the worker are guarded. **Note:** This PR depends on CAMEL-24133 (also included in this branch) which fixes a related pooled exchange factory release issue in the same processors. - [CAMEL-24134](https://issues.apache.org/jira/browse/CAMEL-24134) ## Test plan - [x] New `ResilienceTimeoutWriteBackRaceTest` — slow processor (3s) with short timeout (500ms), verifies fallback result survives after worker completes - [x] New `FaultToleranceTimeoutWriteBackRaceTest` — same pattern for MicroProfile Fault Tolerance - [x] All existing resilience4j tests pass - [x] All existing microprofile-fault-tolerance tests pass 🤖 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]
