I see several intertwined issues here, so I'm filing them all in one place.
1. If I have an @Asynchronous method with @Retry and the invocation fails, it will never be retried. The retry logic is implemented in HystrixCommandInterceptor.interceptCommand, but for the async case, the only thing that happens is that the command is submitted for execution (and the submission is an operation that will succeed), a HystrixCommandInterceptor.AsyncFuture is created as a result of the operation, and is returned – right in the first iteration of the retry loop. Clearly the MP FT spec says that @Asynchronous can be combined with @Retry, but we don't support that. If the operation fails (see below), we'll never retry.
2. This is most likely a spec issue – an @Asynchronous method can fail in two ways: it itself can throw an exception (synchronously), or it can return a failing Future. The spec doesn't say which of these is considered a failure that should be retried. I'd personally suggest both.
3. If the @Asynchronous @Retry method also has a @Fallback, this isn't considered at all. If the failure is a synchronously thrown exception, Hystrix complains that HystrixRuntimeException: <method> failed and no fallback available. This is because when we create the Hystrix command (DefaultCommand), we only pass in the fallback supplier when there's no retry or the current retry loop iteration is the last one (which, per item 1 above, it never is). If the failure is an asynchronous one (failed Future), it's even worse – the HystrixCommandInterceptor.AsyncFuture.unwrap method will just throw IllegalStateException with the message of Unable to get the result of: <Future>.