Profile not correct with SpringBoot 2.4.1 + Ilford 2020.0.0 (working with 2.4.1 + Ilford 2020.0.0-RC1)

[patpatpat123]

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

[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

[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.

[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"
      }
    }
  ]
}

[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.

[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

[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