Suggestions for the modification of 'retrievedServiceInstance == null' in RetryableFeignBlockingLoadBalancerClient#execute

Is your feature request related to a problem? Please describe.

The same interface behaves completely differently in my projects. In one case, it throws a FeignException$ServiceUnavailable exception, while in the other, it throws an UnknownHostException (And it took up to 10 seconds).

After debugging, I found that the inconsistent exception behaviors were caused by the varying implementations of the feign.Client class due to the involvement of spring-retry.

Describe the solution you'd like

The RetryableFeignBlockingLoadBalancerClient appears to reference the handling approach of RetryLoadBalancerInterceptor, but it doesn't perform special handling for the case where serviceInstance == null, unlike FeignBlockingLoadBalancerClient.

I feel that for the case where serviceInstance == null, after retry attempts are exhausted, the RetryableFeignBlockingLoadBalancerClient should return a result similar to that of the FeignBlockingLoadBalancerClient.

Describe alternatives you've considered

I referenced the handling of the serviceInstance == null case in FeignBlockingLoadBalancerClient and modified RetryableFeignBlockingLoadBalancerClient accordingly. It now perfectly meets my expectations.

Additional context

In the code at RetryableFeignBlockingLoadBalancerClient.java:191, within the LoadBalancerUtils.executeWithLoadBalancerLifecycleProcessing method, the feign.Client is directly used to execute the request. Due to the reason that serviceInstance == null, the Client attempts to resolve the host (serviceId), this took too long.

Start in RetryableFeignBlockingLoadBalancerClient.java around line 191 and trace LoadBalancerUtils.executeWithLoadBalancerLifecycleProcessing. Compare its serviceInstance == null handling with FeignBlockingLoadBalancerClient, then verify that exhausted retries avoid direct host resolution and produce the expected unavailable-service result.