[jira] [Created] (CAMEL-24134) camel-resilience4j / camel-microprofile-fault-tolerance - Circuit Breaker EIP: timed-out task writes results back to the original exchange, racing with fallback processing

["Federico Mariani (Jira)" <ji...@apache.org>]

Federico Mariani created CAMEL-24134:
----------------------------------------

             Summary: camel-resilience4j / camel-microprofile-fault-tolerance - Circuit Breaker EIP: timed-out task writes results back to the original exchange, racing with fallback processing
                 Key: CAMEL-24134
                 URL: https://issues.apache.org/jira/browse/CAMEL-24134
             Project: Camel
          Issue Type: Bug
          Components: eip, camel-microprofile-fault-tolerance
    Affects Versions: 4.21.0
            Reporter: Federico Mariani


In both Circuit Breaker implementations, the protected processor runs on a correlated copy of the exchange, but the worker thread writes the outcome back to the *original* exchange with no guard against the caller having already moved on after a timeout.

camel-resilience4j, {{ResilienceProcessor.processTask()}} (the identical pattern exists in {{FaultToleranceProcessor.CircuitBreakerTask.call()}} with SmallRye's thread offload):

{code:java}
// handle the processing result
if (copy.getException() != null) {
    exchange.setException(copy.getException());
} else {
    // copy the result as its regarded as success
    ExchangeHelper.copyResults(exchange, copy);
    exchange.setProperty(ExchangePropertyKey.CIRCUIT_BREAKER_RESPONSE_SUCCESSFUL_EXECUTION, true);
    ...
}
{code}

When the TimeLimiter (or SmallRye timeout) fires, the calling thread immediately runs the fallback and continues routing on the original exchange. Meanwhile the worker thread - unless it happens to be blocked at an interruptible point, and always when {{timeoutCancelRunningFuture=false}} - eventually completes and executes the write-back above, concurrently mutating the same original exchange:

* it can overwrite the fallback result with the late result;
* it can reinstate an exception after the fallback cleared it;
* {{ExchangeHelper.copyResults}} is not atomic, so body/headers/properties can interleave with the route's own processing.

The exchange copy only protects against *downstream processors* mutating the exchange during timeout processing (as the code comment says); the write-back path itself is unguarded.

Suggested fix: the worker must not touch the original exchange once the call has timed out - e.g. a per-task completed/timed-out flag (CAS) checked before the write-back, or perform the write-back on the caller side only when the future completed within the timeout.

_Filed by Claude Code on behalf of Federico Mariani (fmariani)_



--
This message was sent by Atlassian Jira
(v8.20.10#820010)