CXF-9257: Complete client futures if the async callback throws

[markusheiden]

If the callback of an asynchronous client invocation throws, the future returned by the invocation may never complete, so threads blocked in Future.get() hang forever.

CXF callers are expected to invoke ClientCallback.handleException() if handleResponse() throws. This PR:

• fixes the call sites that don't follow that contract: WebClient's ClientAsyncResponseInterceptor and the fault observer wrapper in ClientImpl;
• guards the failure paths inside JaxrsClientCallback and JaxwsClientCallback (handleException(), cancel(), the interruption path of JaxrsResponseFuture.get()). Callers can't complete the future if handleException() itself throws, because the future is owned by the callback. If the user's callback throws there, the original exception is kept and the callback's exception is attached as suppressed (unless it is the same instance).

Unit tests for both callbacks and a WebClient system test in JAXRSAsyncClientTest are included. Details in https://issues.apache.org/jira/browse/CXF-9257.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Ka6VjhpAcDrSERoiLP2Cxx

[reta]

Thanks for the change @markusheiden , the way CXF manages callback:

                try {
                    callback.handleResponse(resCtx, obj);
                } catch (Throwable ex) {
                    callback.handleException(resCtx, ex);
                }

There are some gaps in WebClient indeed which violate that (like you mentioned, ClientAsyncResponseInterceptor), I think the way to fix the issue would be to change ClientAsyncResponseInterceptor (and possibly other places) but not the callbacks. Hope it make sense.

[markusheiden]

Thanks for the fast review @reta. I've reverted the guards in handleResponse and instead fixed the call sites that don't follow the contract (WebClient's ClientAsyncResponseInterceptor and the fault observer wrapper in ClientImpl), with a system test in JAXRSAsyncClientTest. I kept the guards on the failure paths in the callbacks (handleException, cancel, and the interrupted get): if the user's handler throws there, the caller has no way left to complete the future, since it belongs to the callback. In the original BingAds case, the AsyncHandler throws again when it's invoked from handleException, so the future still hung.

I added a table comparing the old and the new approach to https://issues.apache.org/jira/browse/CXF-9257 .

[reta]

Thank you @markusheiden