Describe the bug When starting a Spring Cloud Config Client in a native image, having the environment variable SPRING_CLOUD_CONFIG_FAIL_FAST=true, the image fails silently without any message, even when the Config Server is available. With SPRING_CLOUD_CONFIG_FAIL_FAST=false the image starts successfully, and the logs show that the configuration was fetched from the Config Server.

I would expect that the image only fails, when no configuration can be fetched from the config server for whatever reason.

Is there some additional configuration needed on my side?

Comment From: ryanjbaxter

@OlgaMaciaszek is this something you have tried? Any ideas?

Comment From: OlgaMaciaszek

Will take a look at it. Thanks.

Comment From: OlgaMaciaszek

Hello @MatthiasDrews, thanks for reporting the issue. If fail-fast is set to true and property source cannot be located, the native image startup fails, which is a correct behaviour. However, I agree that it would be better if something was logged. Will look further into it.

Comment From: MatthiasDrews

Hi @OlgaMaciaszek . With fail-fast set to true and config-server being available, the startup failed. Possibly the property source could not be located, this might be the reason for the startup failing. But without any output this is hard to detect or even fix from a user-perspective. So any output is crucial.

Comment From: OlgaMaciaszek

I was not able to reproduce the issue with config server available. Have you tried connecting to the same server without fail-fast set to true. Have you got any output from that?

Comment From: MatthiasDrews

Yes, with fail-fast set to false, the image is starting, and I see the config has been fetched from the config-server. So the connection is working:

13:10:30.473 [main] INFO  c.a.e.... - Starting AOT-processed ...App using Java 17.0.7 with PID 1 (/workspace/......App started by cnb in /workspace)
13:10:30.473 [main] DEBUG c.a.e.... - Running with Spring Boot v3.1.5, Spring v6.0.13
13:10:30.473 [main] INFO  c.a.e.... - The following 3 profiles are active: "emea", "dev", "emea-dev"
13:10:30.473 [main] INFO  o.s.c.c.c.ConfigServerConfigDataLoader - Fetching config from server at : http://host.docker.internal:8888
13:10:30.473 [main] INFO  o.s.c.c.c.ConfigServerConfigDataLoader - Located environment: name=..., profiles=[default], label=null, version=latest, state=null
13:10:30.473 [main] INFO  o.s.c.c.c.ConfigServerConfigDataLoader - Fetching config from server at : http://host.docker.internal:8888
13:10:30.473 [main] INFO  o.s.c.c.c.ConfigServerConfigDataLoader - Located environment: name=..., profiles=[emea,dev,emea-dev], label=null, version=latest, state=null
...
13:10:32.653 [main] INFO  c.a.e.... - Started ...App in 2.887 seconds (process running for 2.865)

Comment From: OlgaMaciaszek

Thanks for the information @MatthiasDrews; it's still probably something in your environment causing the issue, since we could not replicated, but the output will be needed to determine what.

Comment From: OlgaMaciaszek

Will consult with GraalVM team.

Comment From: OlgaMaciaszek

This is issue affects not only Spring Cloud Config, but also Spring Boot. Closing in favour of https://github.com/spring-projects/spring-boot/issues/39742. @MatthiasDrews please see https://github.com/spring-projects/spring-boot/issues/39742#issuecomment-1961654290 for a workaround.

Comment From: MatthiasDrews

Thank you! The suggested workaround works for me, and I get logs now.

The startup currently fails, because the ConfigClientRetryBootstrapper runs into a NullPointerException. I have spring-retry as a transitive dependency, which relies on reflection. This of course does not work in the native image. Probably I can find another workaround for this problem, now that the logs can be seen.

Comment From: OlgaMaciaszek

@MatthiasDrews You might want to add some custom hints or report an issue with spring-retry if some of the classes from that project do not register the required native hints.