Eureka First Bootstrap & retry defaulting to localhost

We've three Spring Boot applications:

• Eureka Service
• Config Server
• Simple Web Service making use of Eureka and Config Server

I've set up the services so that we use a Eureka First Bootstrap, i.e. the simple web application finds out about the config server from the eureka service.

When started separately (either locally or by starting them as individual docker images) everything is ok, i.e. start config server after discovery service is running, and the Simple web service is started once the config server is running.

When docker-compose is used to start the services, they obviously start at the same time and essentially race to get up and running. This isn't an issue as we've added failFast: true and retry values to the simple web service and also have the docker container restarting so that the simple web service will eventually restart at a time when the discovery service and config server are both running but this doesn't feel optimal.

The simple web service reattempts a number of times to connect to the discovery service. This is sensible and expected. The unexpected behaviour we noticed was the following:

• At the same time the simple web service attempts to contact the config server. Because it cannot contact the discovery service, it retries to connect to a config server on localhost, e.g. logs show retries going to http://localhost:8888.
• If you configure your retry to be sufficiently long, the simple web service will eventually successfully connect to the discovery service but the logs show it stills tries to establish communication to the config server by going to http://localhost:8888. Again, this wasn't ideal.

Three questions/observations:

• Is it a sensible strategy for the config client to fall back to trying localhost:8888 when it has been configured to use discovery to find the config server?
• When the eureka connections is established, should the retry mechanism not now switch to trying the config server endpoint as indicated by Eureka? Essentially putting in higher/longer retry intervals and periods for the config server connection is pointless in this case as it's never going to connect to it if it's looking at localhost so we're better just failing fast.
• Are there any properties that can override this behaviour?
  I've created a sample github repo that demonstrates this behaviour:

https://github.com/KramKroc/eurekafirstdiscovery/tree/master

Start with the sample repository linked in the issue and reproduce the Docker Compose startup race, focusing on the simple web service's Eureka and Config Server retry logs. Compare the configured discovery-based endpoint with the localhost fallback and determine the expected retry behavior and available configuration overrides; completion requires a verified resolution or documented limitation.