Feature Request - Config Server returns a 400 if it cannot find a file of the application's name

Consider the following scenario.

We have a single Config Server and about 30-40 different applications receive their configurations from the Config Server . Out of this about 8 applications have a Kafka Consumer running inside them , and 7 applications(consumers) are listening to a topic belong to the same consumer group. The name of the group is given by the property , lets say consume.group. As , this config is shared by 7 applications , we decide to put it in application.yml/properties for convenience . Now, the remaining(8th) application(consumer) is consuming messages from same topic but with a different consumer group name , so we decide to create a file called test8-dev.yml/properties(test8 is name of application and dev is profile). Here, we insert the property consume.group , so this value overrides the property in application.yml.

Now the issue which could happen in the above case is if the property spring.application.name is not given(human-error) or it is mispelled or the file test8-dev.yml/properties is not found(maybe accidently removed), is that the application by the name of test8 will consume belonging to a consumer group , it should not belong to and would try to accomplish some other goal. This will make the consumer group lose some messages as those messages are being consumed by an application(test8) for whom they are not meant for.

I decided to go with the Kafka Consumer example , to show the gravity of what the above situation could do.

I propose that we add an optional header in the Config Client when it makes a request , indicating that this application expects to get properties from a file by the application's name . In such a case ,If the config Server does not find a file by the name of application , it will return a 400(Bad request) with the error message. This would be better , as the application won't start because properties won't be found , and the person deploying would automatically know that something is wrong ( because the application fails to start ) and no damage would be done .

Start by tracing how the Config Client constructs requests and how the Config Server handles missing application-named files. Done means an optional client signal can require that file and the server returns HTTP 400 with an error when it is absent, while existing requests retain their current behavior.