SpringBoot ConfigDataLocationNotFoundException thrown at application startup with configserver: config imports, that are not even meant for the current profile

Since upgrading from 2.4.0 to 2.4.1 (same for 2.4.2-SNAPSHOT) my application fails to startup due the following exception; - Using Spring Cloud version 2020.0.0-RC1

06:46:34.776 [main] DEBUG org.springframework.boot.diagnostics.LoggingFailureAnalysisReporter - Application failed to start due to an exception
org.springframework.boot.context.config.ConfigDataLocationNotFoundException: Config data location 'configserver:https://prod-configuration-server.org' cannot be found
    at org.springframework.boot.context.config.ConfigDataEnvironment.checkMandatoryLocations(ConfigDataEnvironment.java:360)
    at org.springframework.boot.context.config.ConfigDataEnvironment.applyToEnvironment(ConfigDataEnvironment.java:313)
    at org.springframework.boot.context.config.ConfigDataEnvironment.processAndApply(ConfigDataEnvironment.java:233)
    at org.springframework.boot.context.config.ConfigDataEnvironmentPostProcessor.postProcessEnvironment(ConfigDataEnvironmentPostProcessor.java:97)
    at org.springframework.boot.context.config.ConfigDataEnvironmentPostProcessor.postProcessEnvironment(ConfigDataEnvironmentPostProcessor.java:89)
    at org.springframework.boot.env.EnvironmentPostProcessorApplicationListener.onApplicationEnvironmentPreparedEvent(EnvironmentPostProcessorApplicationListener.java:100)
    at org.springframework.boot.env.EnvironmentPostProcessorApplicationListener.onApplicationEvent(EnvironmentPostProcessorApplicationListener.java:86)

I think this is originally caused by improvements made in https://github.com/spring-projects/spring-boot/commit/3dc03ac2752a06e015fc8ae7a6eba483b2cc863e

This occurs with the following setup; (starting up with both default profile as the local profile (-Dspring.profiles.active=local)

spring:
  application:
    name: foobar
  profiles:
    active: local

---

spring:
  config:
    activate:
      on-profile: local, docker
    import: configserver:http://localhost:8888

---

spring:
  config:
    activate:
      on-profile: dev, test
    import: configserver:https://test-configuration-server.org

---

spring:
  config:
    activate:
      on-profile: acc
    import: configserver:https://acc-configuration-server.org

---

spring:
  config:
    activate:
      on-profile: prd
    import: configserver:https://prod-configuration-server.org

In my understanding this exception is thrown because all mandatory locations are checked, and not just one from the active profile. I would expect it to nicely skip the configserver: imports for both dev, test, acc, prd in the above example. Even though they are not optional, they are not meant for the active profile either.

Comment From: spencergibb

What version of Spring Cloud are you using?

Comment From: dnijssen

Using Spring Cloud version 2020.0.0-RC1, as I did with Spring Boot 2.4.0 as well before. So the breaking change seems to be part of Spring Boot

Comment From: snicoll

So the breaking change seems to be part of Spring Boot

@dnijssen Using an old Spring Cloud version against a newer spring boot version isn't the right thing to do. This feature is tightly integrated in Spring Cloud and we had to do some changes in 2.4.1 to help ironing things in Spring Cloud config server. Please try with the latest Spring Cloud 2020.0.0.

Edit: To make that hopefully more clear, 2020.0.0-SNAPSHOT.

Comment From: dnijssen

Same issue occurs when running Spring Boot 2.4.1 with Spring Cloud 2020.0.0-SNAPSHOT

backend_1   | 08:41:37.871 [main] DEBUG org.springframework.boot.diagnostics.LoggingFailureAnalysisReporter - Application failed to start due to an exception
backend_1   | org.springframework.boot.context.config.ConfigDataLocationNotFoundException: Config data location 'configserver:https://prod-configuration-server.org' cannot be found
backend_1   |   at org.springframework.boot.context.config.ConfigDataEnvironment.checkMandatoryLocations(ConfigDataEnvironment.java:344)
backend_1   |   at org.springframework.boot.context.config.ConfigDataEnvironment.applyToEnvironment(ConfigDataEnvironment.java:300)
backend_1   |   at org.springframework.boot.context.config.ConfigDataEnvironment.processAndApply(ConfigDataEnvironment.java:224)
backend_1   |   at org.springframework.boot.context.config.ConfigDataEnvironmentPostProcessor.postProcessEnvironment(ConfigDataEnvironmentPostProcessor.java:88)
backend_1   |   at org.springframework.boot.context.config.ConfigDataEnvironmentPostProcessor.postProcessEnvironment(ConfigDataEnvironmentPostProcessor.java:80)

Comment From: mbhave

Thanks for checking @dnijssen. I was able to reproduce this in Spring Boot. I think it's a bug that we check mandatory locations even when the profile isn't active.

Comment From: dnijssen

Thank you for confirming @mbhave , I have just verified the same thing as well on advice of @spencergibb. He asked me to check whether the same thing was happening when just using file:./non-existing.yaml. And it indeed exists in that case as well, confirming the bug that you described above, namely checking mandatory locations for inactive profiles.

Comment From: snicoll

@mbhave shouldn't this be flagged a regression?