It appears that in discovery-first mode, the config client is not updating its location information for the config server when that data changes in eureka (i.e. when a config server instance is removed or added in eureka). Is this currently expected behavior, or am I doing something wrong?

my bootstrap config:

spring:
    cloud:
        config:
            enabled: true
            failFast: true
            discovery:
                enabled: true
eureka:
    client:
        serviceUrl:
            defaultZone: [[my eureka defaultZone]]

When I take down the first config server instance, the configserver healthcheck in the app begins to fail despite there being a second working node registered with eureka. The same occurs if I restart the config server node with a new password in the eureka metadataMap, in which case the client keeps trying to use the old password.

Comment From: spencergibb

spring.cloud.config.discovery.enabled=true is currently built on a one time eureka lookup. It is not built with ribbon (ie a client-side load balancer).

Comment From: whboyd

Is this something that you might like to see a PR on?

Comment From: spencergibb

Yes, we'd want to make sure it's well tested and easy to understand.

Comment From: whboyd

I'll give it a shot

Comment From: superwen0001

DiscoveryClientConfigServiceBootstrapConfiguration heartbeat event triggers the refresh config. Uri. It holds EurekaClient is old, the EurekaClient should be a singleton, but the introduction of the config is created twice, causing it to refresh for the config address is still not available

Comment From: xiaods

any update?

Comment From: vnicers

any update?

Comment From: madogao

+1 any update?

Comment From: ryanjbaxter

If there was an update it would have been posted here

Comment From: lahcloud

any update?

Comment From: xiaobai1202

any update ?

Comment From: bberto

I think the analysis done here can be useful spring-cloud/spring-cloud-netflix#3675

During startup a DiscoveryClient is created on bootstrap context and then shut down. Then DiscoveryClient is restarted, but ConfigServerInstanceProvider continues to use the shutdown bean, getting no updates.

This makes discovery-first bootstrap working only if config server is already registered on Eureka when config client starts.

Comment From: nikfuri

I have same issue with ReactiveEurekaDiscoveryClient. It is configured with DiscoveryClient which is used during bootstrap, then this client is shut down and never refresh, and loadbalancer never gets instances updates.

Comment From: k631583871

You can subscribe to the spring-cloud/spring-cloud-netflix#3675 questi

Comment From: spencergibb

There's no need to comment on multiple issues. GitHub links them automatically.

Comment From: pivotghub

I this issue fixed now ? If yes then which version we can follow ?

Comment From: OlgaMaciaszek

Avoid using EurekaClient in order to fix this issue and the following issues in SC Netflix: #3708, #3675.