Issue Description

🐞 Bug Report

When using Spring Cloud Netflix Eureka Server, a bean conflict occurs in EurekaInstanceMeterBinder due to multiple task executors being found. This issue arises because both applicationTaskExecutor and taskScheduler are present in the Spring context, causing ambiguity when injecting a single bean.

📌 Error Message

Parameter 3 of method eurekaInstanceMeterBinder in org.springframework.cloud.netflix.eureka.server.metrics.EurekaInstanceMetricsAutoConfiguration 
required a single bean, but 2 were found:
- applicationTaskExecutor: defined by method 'applicationTaskExecutor' in class path resource 
  [org/springframework/boot/autoconfigure/task/TaskExecutorConfigurations$TaskExecutorConfiguration.class]
- taskScheduler: defined by method 'taskScheduler' in class path resource 
  [org/springframework/boot/autoconfigure/task/TaskSchedulingConfigurations$TaskSchedulerConfiguration.class]

🎯 Steps to Reproduce

Set up a Spring Cloud Netflix Eureka Server.
Include spring-boot-starter-actuator in the dependencies.
Start the application.
The application fails to start due to a bean conflict in EurekaInstanceMeterBinder.

🛠 Expected Behavior

The application should start without any bean conflict, and EurekaInstanceMeterBinder should properly select a task executor.

⚡️ Workaround (Temporary Solution)

A possible workaround is explicitly defining a single task executor bean in the application configuration:

@Bean
public TaskExecutor taskExecutor(TaskExecutorBuilder builder) {
    return builder.build();
}

Alternatively, specifying the bean name explicitly in EurekaInstanceMeterBinder might resolve the issue.

🌍 Environment

Spring Boot Version: 3.4.2
Spring Cloud Version: 2024.0.0
Java Version: 17

🔗 Related PR

https://github.com/spring-cloud/spring-cloud-netflix/pull/4376

📌 Additional Context

This issue might be related to how Spring Boot’s TaskExecutor and TaskScheduler beans are being automatically configured, causing multiple candidates when Eureka’s metrics binder attempts to inject a single bean. Please confirm if this is an intended behavior or if an improvement can be made to handle this bean conflict more gracefully.🙏🏻

Comment From: OlgaMaciaszek

Hello, @johnycho. Thanks for reporting the issue. I have set up a sample branch following your steps, but was not able to reproduce the issue. Please provide a minimal, complete, verifiable example that reproduces the issue.

Comment From: johnycho

Hello, @johnycho. Thanks for reporting the issue. I have set up a sample branch following your steps, but was not able to reproduce the issue. Please provide a minimal, complete, verifiable example that reproduces the issue.

Hello, @OlgaMaciaszek. Thanks for your response.

I was able to reproduce the issue after adding the @EnableScheduling annotation. It seems that enabling scheduling affects the behavior.

Could you confirm if this aligns with your observations?

Looking forward to your response. Thanks!