gnodet commented on PR #24426: URL: https://github.com/apache/camel/pull/24426#issuecomment-4884023522
_Claude Code on behalf of @squakez_ @ammachado Thank you for the review and good questions! 1. **CI run link**: You're right — the investigation confirmed that the linked CI run was actually cancelled (not failed due to CXF), and the `CxfConsumerPayLoadFaultMessageTest` test **did pass** in that run. The flakiness was reported in [CAMEL-23909](https://issues.apache.org/jira/browse/CAMEL-23909) based on observed intermittent failures on JDK 25. The root cause analysis identified that the fault detection path was fragile — it relied on CXF's internal response serialization behavior to handle a `CxfPayload` containing a raw `<soap:Fault>` element through the normal (non-fault) path, which could behave inconsistently depending on JDK/CXF internals. 2. **Migration guide**: This is a bug fix rather than a behavior change — when a route sets a `CxfPayload` containing a `<soap:Fault>` element as the message body, the clear intent is to return a SOAP fault to the client. The old code only detected `Throwable` bodies, so the fault XML was serialized through CXF's normal response path instead of the fault handling path. The fix makes this pattern behave consistently with the other two existing fault patterns: - `exchange.setException(soapFault)` — detected by `checkFailure()` (works correctly) - `exchange.getMessage().setBody(soapFault)` — detected by `extractFromBody()` since `SoapFault` is a `Throwable` (works correctly) - `exchange.getMessage().setBody(cxfPayload)` — **was not detected**, now fixed Since the end result for the client is the same SOAP fault response (just now going through the correct CXF fault pipeline), I don't think a migration guide entry is needed. No user would intentionally rely on a `CxfPayload<soap:Fault>` body *not* being treated as a fault. -- 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]
