Describe the bug Starting with 2022.0.3 we noticed profile specific properties we store in the AWS Parameter Store and Secretsmanager were no longer available in our applications.
I was able to trace the issue to this part of newly introduced code in the client that parses the property source name returned by the config server. It appears to assume the profile separator can only ever be - or ,. However, we use the spring.cloud.config.server.awsparamstore.profile-separator and spring.cloud.config.server.awssecretsmanager.profile-separator properties to use _ as a custom profile separator. The referenced client code fails to recognize this as a profile specific property source, causing it to be filtered out. According to the documentation underscore (and dot) are valid profile separators.
Specifically we have a secret named /secret/application-name_profile/, which results in a property source with name configserver:aws:secrets:/secret/application-name_profile/, which does not match the .*[-,]profile.* regex despite it being a profile specific property source.
Sample I hope the above is sufficient, I will try to get around to reproducing the issue in isolation.
Comment From: ryanjbaxter
That code existed in 2022.0.2 as well
https://github.com/spring-cloud/spring-cloud-config/blob/v4.0.2/spring-cloud-config-client/src/main/java/org/springframework/cloud/config/client/ConfigServerConfigDataLoader.java#L169
Maybe it was a different change
Comment From: ryanjbaxter
What changed was this line !applicationName.equals(extractApplicationName(propertySource))
Comment From: ryanjbaxter
The problem is actually this code
https://github.com/spring-cloud/spring-cloud-config/blob/cdb87ff48ae0646ee513d0acede672dc625c22a4/spring-cloud-config-client/src/main/java/org/springframework/cloud/config/client/ConfigServerConfigDataLoader.java#L158-L162
I am unsure how best to deal with this because the config client has no idea how the config server profile separator is configured.
The best we could do is just return all property sources if the the property source name has aws but none will be labeled PROFILE_SPECIFIC. I suppose that wouldn't be an issue because that is essentially what happened before since the previous code wouldn't have worked either.