Property Source Beans out of order when Config Server not available at startup, but later becomes available

[stwomack]

"applicationConfig: [classpath:/application.properties]": {
"message": "This IS the default message packaged in the application!"
},
"applicationConfig: [classpath:/bootstrap.yml]": {
"spring.application.name": "config-client-test",
"spring.cloud.config.uri": "http://localhost:8000",
"server.port": 8888,
"management.security.enabled": false
},

When a config client app is started & its config server is unreachable, there's no property sources from the server initially. But when the config server does become available, and a /refresh POST is done, the config client will now connect to the config server, but the property sources from the config server will be lower in precedence than the initially loaded property sources (from classpath, etc.) and thus the application will not now override properties from the config server. The applicationConfig beans after the client has finally connected are ordered as follows (meaning the client app still uses what it initially loaded, instead of the properties from the config server):

"applicationConfig: [classpath:/application.properties]": { "message": "This IS the default message packaged in the application!" }, "applicationConfig: [classpath:/bootstrap.yml]": { "spring.application.name": "config-client-test", "spring.cloud.config.uri": "http://localhost:8000", "server.port": 8888, "management.security.enabled": false },
"configService:configClient": {
"config.client.version": "5fb8eb09959a3601cb310f68f8ac6dc0ed66816b"
},

[martin-tarjanyi]

I've experienced the same. It is an unlikely scenario to happen but if it happens it is very unfortunate, since you need to restart your client app to get the config from the server. I wonder if it is a bug or there is some intention behind it.