Exclude @LoadBalanced RestClient/WebClient builders from Eureka transport by arimu1 · Pull Request #4602 · spring-cloud/spring-cloud-netflix

arimu1 · 2026-09-13T00:38:41Z

Summary

Resolve Eureka registry RestClient.Builder / WebClient.Builder candidates by excluding beans annotated with @LoadBalanced, so calls to the Eureka server URL are not routed through the load balancer (fixes No instances available for localhost when only a load-balanced builder is registered).
Fall back to RestClient.builder() / WebClient.builder() when every registered builder is load-balanced.
Add context tests covering RestClient-only, plain+load-balanced, and WebClient-only setups.

Fixes gh-4591 (same root cause as gh-4524).

Test plan

./mvnw -pl spring-cloud-netflix-eureka-client -Dtest=LoadBalancedEurekaHttpClientBuilderConfigurationTests test (JDK 21)
./mvnw -pl spring-cloud-netflix-eureka-client -am test — module suite passes except pre-existing EurekaConfigServerBootstrapperIntegrationTests (Docker not available locally)

@LoadBalanced

Eureka registry calls must not use load-balanced RestClient or WebClient builders. Filter @LoadBalanced beans when resolving builders and fall back to plain factory methods when needed. Fixes spring-cloudgh-4591 Signed-off-by: arimu1 <19286898+arimu1@users.noreply.github.com>

arimu1 · 2026-09-21T10:41:19Z

Thanks for the review @ryanjbaxter — addressed all three points in eb419ef:

@order / @priority — After filtering out @LoadBalanced candidates, the remaining bean names are sorted with DefaultListableBeanFactory.getOrder(beanName) (with @Order / @Priority / Ordered fallback when the factory is not a DefaultListableBeanFactory), so the highest-precedence non–load-balanced builder is chosen.
Resolve once — restClientBuilder / webClientBuilder now resolve the selected builder when the supplier is created and return a supplier that always hands back that same instance (callers still .clone() per transport client as before).
WebClient test — Added webClientTransportPrefersPlainWebClientBuilderOverLoadBalanced, mirroring the existing RestClient plain-vs-load-balanced test.

Tests: ./mvnw -pl spring-cloud-netflix-eureka-client -Dtest=LoadBalancedEurekaHttpClientBuilderConfigurationTests test — 4 tests, BUILD SUCCESS (Temurin 21).

@LoadBalanced

Resolve the non-@LoadBalanced RestClient/WebClient builder once at configuration time using DefaultListableBeanFactory order metadata. Add WebClient plain-over-load-balanced configuration test. Signed-off-by: arimu1 <19286898+arimu1@users.noreply.github.com>

arimu1 · 2026-09-21T10:41:56Z

Force-pushed amended commit (removed erroneous trailer): tip is now 3f39a858c — same changes as noted above.

ryanjbaxter · 2026-09-21T18:37:31Z

+	}
+
+	private static int orderFor(ConfigurableListableBeanFactory beanFactory, String beanName) {
+		if (beanFactory instanceof DefaultListableBeanFactory defaultListableBeanFactory) {


This will cause the bean to be instantiated. IMO we can just use beanFactory.findAnnotationOnBean here and if there isn't an annotation then treat it as Ordered.LOWEST_PRECEDENCE

@priority

Use findAnnotationOnBean for @Order/@priority and require @primary or unique precedence when multiple non-@LoadBalanced builders exist, instead of DefaultListableBeanFactory.getOrder(). Signed-off-by: arimu1 <19286898+arimu1@users.noreply.github.com>

ryanjbaxter · 2026-09-26T14:25:41Z

+	}
+
+	static Supplier<RestClient.Builder> restClientBuilder(ConfigurableListableBeanFactory beanFactory) {
+		RestClient.Builder builder = resolveNonLoadBalancedBuilder(beanFactory, RestClient.Builder.class,


This should be wrapped in a SingletonSupplier.of to prevent early initialization

ryanjbaxter · 2026-09-26T14:25:46Z

+	}
+
+	static Supplier<WebClient.Builder> webClientBuilder(ConfigurableListableBeanFactory beanFactory) {
+		WebClient.Builder builder = resolveNonLoadBalancedBuilder(beanFactory, WebClient.Builder.class,


This should be wrapped in a SingletonSupplier.of to prevent early initialization

kdelay

One regression to flag: getBeanNamesForType only looks at the current factory, while the ObjectProvider this replaces also resolved beans from ancestor contexts. With a plain RestClient.Builder defined only in a parent context, main hands that bean to the transport; on this branch it falls back to RestClient.builder(). I checked it with a WebApplicationContextRunner().withParent(...) test (passes on main, fails here).

Using BeanFactoryUtils.beanNamesForTypeIncludingAncestors(beanFactory, type) restores it; with that change the new test and the 7 tests here all pass.

@LoadBalanced

Parent contexts were invisible to getBeanNamesForType, so a plain RestClient.Builder defined only there was skipped. Look up ancestor bean names and read @LoadBalanced, @order, and @primary on the factory that defines the bean. Defer that resolution until the supplier is first used. Signed-off-by: arimu1 <19286898+arimu1@users.noreply.github.com>

arimu1 · 2026-10-11T15:23:18Z

Thanks @kdelay — f730c4050 uses BeanFactoryUtils.beanNamesForTypeIncludingAncestors, and reads @LoadBalanced / @Order / @Primary from the factory that defines the bean, so a load-balanced builder that exists only in a parent is still skipped.

Both suppliers are also SingletonSuppliers, so that lookup waits until first use.

LoadBalancedEurekaHttpClientBuilderConfigurationTests: 9 tests, 0 failures on JDK 21, including a plain builder defined only in a parent and a load-balanced builder defined only in a parent.

ryanjbaxter · 2026-10-12T20:59:40Z

+			throw new NoUniqueBeanDefinitionException(type, primary.size(),
+					"more than one @Primary non-@LoadBalanced " + type.getSimpleName() + " bean: " + primary);
+		}
+		candidates.sort(


It seems like you are calling orderFor on the candidates here and in the for loop below. That doesn't seem necessary

arimu1 · 2026-10-27T00:33:14Z

orderFor now runs once per candidate. The tie break reads that map instead of calling it again from the sort and the loop. Tip 97a156bd4. LoadBalancedEurekaHttpClientBuilderConfigurationTests passed on JDK 17, and spring-javaformat:validate is clean.

Signed-off-by: arimu1 <19286898+arimu1@users.noreply.github.com>

arimu1 · 2026-10-27T00:37:06Z

DCO sign-off is on tip a16d518d8 (same change as 97a156bd4).

ryanjbaxter · 2026-10-27T21:11:22Z

+	private static <T> T resolveNonLoadBalancedBuilder(ConfigurableListableBeanFactory beanFactory, Class<T> type,
+			Supplier<T> fallback) {
+		List<String> candidates = new ArrayList<>();
+		for (String name : BeanFactoryUtils.beanNamesForTypeIncludingAncestors(beanFactory, type)) {


Thanks for adding the ancestor-factory handling. However I think these is a behavior change caused by this. beanNamesForTypeIncludingAncestors pools the parent and child candidates, but the previous ObjectProvider.getIfAvailable() resolved locally first and only fell back to the parent when the child had no match.

Before this PR, and with normal Spring autowiring, the child’s bean would win.

Could we add a test for this?

spring-cloud-issues added the waiting-for-triage label Sep 13, 2026

ryanjbaxter requested changes Sep 17, 2026

View reviewed changes

arimu1 force-pushed the fix/4591-eureka-skip-loadbalanced-restclient branch from eb419ef to 3f39a85 Compare September 21, 2026 10:41

ryanjbaxter requested changes Sep 21, 2026

View reviewed changes

ryanjbaxter requested changes Sep 26, 2026

View reviewed changes

kdelay reviewed Oct 11, 2026

View reviewed changes

ryanjbaxter requested changes Oct 12, 2026

View reviewed changes

fix(eureka-client): read bean order once when breaking precedence ties

a16d518

Signed-off-by: arimu1 <19286898+arimu1@users.noreply.github.com>

arimu1 force-pushed the fix/4591-eureka-skip-loadbalanced-restclient branch from 97a156b to a16d518 Compare October 27, 2026 00:36

ryanjbaxter requested changes Oct 27, 2026

View reviewed changes

Conversation

arimu1 commented Sep 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Test plan

Uh oh!

Uh oh!

Uh oh!

Uh oh!

arimu1 commented Sep 21, 2026

Uh oh!

arimu1 commented Sep 21, 2026

Uh oh!

ryanjbaxter Sep 21, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ryanjbaxter Sep 26, 2026

Choose a reason for hiding this comment

Uh oh!

ryanjbaxter Sep 26, 2026

Choose a reason for hiding this comment

Uh oh!

kdelay left a comment

Choose a reason for hiding this comment

Uh oh!

arimu1 commented Oct 11, 2026

Uh oh!

ryanjbaxter Oct 12, 2026

Choose a reason for hiding this comment

Uh oh!

arimu1 commented Oct 27, 2026

Uh oh!

arimu1 commented Oct 27, 2026

Uh oh!

ryanjbaxter Oct 27, 2026

Choose a reason for hiding this comment

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

arimu1 commented Sep 13, 2026 •

edited

Loading