Hello Spring Cloud Config Team,

Maybe a small bug with Ilford 2020.0.0 and SpringBoot 2.4.1 With a web app, 2.4.1 + Ilford 2020.0.0-RC1, the properties are being picked up correctly at client side. When the client starts, I do see below logs, very happy 😃 

[           main] c.a.Application            : The following profiles are active: my-env
[           main] o.s.b.context.config.ConfigDataLoader    : Fetching config from server at : https://my-service/config
[           main] o.s.b.context.config.ConfigDataLoader    : Located environment: name=myservice, profiles=[my-env], label=null, version=7f95facc49b97272a0a3915650b12e56ea7440bf, state=null


[           main] c.u.j.EncryptablePropertySourceConverter : Converting PropertySource configserver:https://my-git/myservice-my-env.properties [org.springframework.boot.env.OriginTrackedMapPropertySource] to EncryptableMapPropertySourceWrapper

note profiles=[my-env]

However, same code, just one change, Ilford 2020.0.0-RC1 -> Ilford 2020.0.0, the properties are not being picked up. On startup, I am seeing the following instead: 

[           main] c.a.Application            : The following profiles are active: my-env
[           main] o.s.b.context.config.ConfigDataLoader    : Fetching config from server at : https://my-service/config
[           main] o.s.b.context.config.ConfigDataLoader    : Located environment: name=myservice, profiles=[default], label=null, version=7f95facc49b97272a0a3915650b12e56ea7440bf, state=null

[           main] c.u.j.EncryptablePropertySourceConverter : Converting PropertySource Config resource 'class path resource [application.properties]' via location 'optional:classpath:/' [org.springframework.boot.env.OriginTrackedMapPropertySource] to EncryptableMapPropertySourceWrapper

And then again reverted back to 2020.0.0-RC1, and working. May I ask what is the root cause of this issue please?

Thank you

Comment From: dnijssen

I just encountered the same issue, and created a reproduction path for @spencergibb and his team -> https://github.com/dnijssen/config-server-client . Seems to be a regression issue to me, as I can confirm it did indeed work with 2020.0.0-RC1

Comment From: spencergibb

As a workaround to get the config client to send the right profile, set spring.cloud.config.profile to the same values as spring.profiles.active.

Comment From: spencergibb

There is a second issue in config server where the names of the property sources are the same, so Default still gets returned because the correct property source gets overridden.

{
  "name": "config-client",
  "profiles": [
    "test"
  ],
  "label": null,
  "version": null,
  "state": null,
  "propertySources": [
    {
      "name": "class path resource [config/config-client.yaml",
      "source": {
        "spring.config.activate.on-profile": "test",
        "config-client.test": "Test"
      }
    },
    {
      "name": "class path resource [config/config-client.yaml",
      "source": {
        "config-client.test": "Default"
      }
    }
  ]
}

Comment From: dnijssen

Ty for the workaround! I can indeed confirm the second issue as well :) Would you be able to convert that one into a seperate issue yourself? As you might be able better to describe it.

Comment From: ncioj10

Where to apply these workarounds? To me it seems that the configserver pull is completely broken. For me it doesn't even work with legacy processing. It just doesn't pull the files with in application.properties and bootstrap.properties. The documentation is very confusing regarding this, it would be good to have that in a central place as currently it is not clear how to upgrade.

spring.application.name=current-service
spring.cloud.config.uri=http://localhost:8888
spring.config.use-legacy-processing=true

Comment From: spencergibb

They have been fixed in version 3.0.1 see https://github.com/spring-cloud/spring-cloud-release/wiki/Spring-Cloud-2020.0-Release-Notes#known-issues