Deciding what to do when we get a MultiException should probably be handled in the RetryInvocationHandler.
The reason the short-circuit failure path looks incorrect is because it can cause spurious request failures if the standby thinks it is active and throws something other than StandbyException.
Yeah, true. Short-circuit failure path in RequestHedgingInvocationHandler is not a proper solution here.
I had a look at RetryInvocationHandler, MultiException is handled only while constructing RetryInfo in RetryInvocationHandler#RetryInfo#newRetryInfo.
In RetryInvocationHandler#handleException if retryInfo.fail != null the received exception is thrown as it is, which in our case is MultiException(ExecutionException(RemoteException(Exception)))
As you suggested, we can unwrap ExecutionException and throw MultiException(RemoteException(Exception)) from RequestHedgingInvocationHandler.
We still have to handle MultiException in RetryInvocationHandler.
In RetryInvocationHandler, we will get list of RemoteExceptions' from MultiException, from which we can exclude StandbyExceptions'. Is there any other check that can be performed to identify the proper exception to throw back to client?