JDBC Config Server is unhealthy if accept-empty: false

[ilia1243]

Describe the bug
Healthy Spring Cloud Config Server with JDBC backend is considered DOWN, if spring.cloud.config.server.accept-empty=false.

The server still responds properly with 404 or 200 according to the documentation: https://docs.spring.io/spring-cloud-config/reference/server/environment-repository.html and so can be considered healthy.

You can set spring.cloud.config.server.accept-empty to false so that Server would return a HTTP 404 status, if the application is not found.

For example, if there is only one record

INSERT INTO properties (application, profile, label, "KEY", "VALUE")
VALUES ('app1', 'default', 'master', 'key', 'value');

for application that is found the server returns:

curl http://localhost:8080/app1/default

{"name":"app1","profiles":["default"],"label":null,"version":null,"state":null,"propertySources":[{"name":"app1-default","source":{"key":"value"}}]}

and for application that is not found the server returns:

curl http://localhost:8080/app2/default

{"timestamp":"2026-02-12T22:48:26.533Z","status":404,"error":"Not Found","path":"/app2/default"}

This started to reproduce after issue #2749

Sample
https://github.com/ilia1243/spring-cloud-config-allow-empty-unhealthy

[ryanjbaxter]

This is the expected behavior, it should be DOWN when accept-empty is false. If the default health indicator configuration is does not work for your use case you can configure the app, profile, and label it uses to check for health
https://docs.spring.io/spring-cloud-config/docs/current/reference/html/#_health_indicator

[ilia1243]

Hello,

This is the expected behavior, it should be DOWN when accept-empty is false.

In the description of the issue I tried to explain the opposite opinion, namely why one may expect the server should be UP. Could you give reasons why you think this is wrong?

If the default health indicator configuration is does not work for your use case you can configure the app, profile, and label it uses to check for health

This is not reasonable in our case, as the server does not know about its particular clients. We would have to create dummy app with dummy configuration for it. We would need extra efforts to protect such "unused" configuration from being deleted by administrator, because otherwise the server would be constantly restarted by orchestrator. To be honest, it is simpler to disable this health check, and provide the one with old behavior to work around this. Is there an opportunity to avoid work arounds?

[ryanjbaxter]

You are basically suggesting we revert the new behavior and we are not going to do that as we made the decision that this is the correct behavior. You can disable the health check entirely to avoid the restarting of the config server by the platform.

[ilia1243]

What about a new property spring.cloud.config.server.health.accept-empty that would allow empty sources in health check? Consider this as overriding the spring.cloud.config.server.accept-empty.

[ryanjbaxter]

If you want to create a PR to support something like this we can consider it

[ilia1243]

Sure #3192, could you reopen the issue?