Hi,
I have this actuator config in my application:
management:
endpoint:
health:
group:
readiness:
include: rabbit,db,redis
I deploy in a couple of different environments and in some environments REDIS is unavailable and we use EHCACHE instead, the application detects this and does not configure the redis service in the app. In SpringBoot 3.0.6 this works fine - i.e. if REDIS is available and configured it adds to the readiness probe, if it doesn't exist then it is ignored.
When I tried to update to SpringBoot 3.1.1 I found that in the environments where redis is disabled spring boot fatally errors now and refuses to let the application start because the readiness actuator is not available.
To put it another way, in SpringBoot 3.0.6 to use dynamic "optional" readiness probes, one would add all the probes that "might" be present and spring would ignore the missing ones at runtime. How in this new "strict" world of SpringBoot 3.1.1 would one achieve the same behaviour? I could add config to each environment to specify the value of this field, but that would be very hard to synchronise with the code that automatically enables / disables the redis in the application it was more "correct" the old way.
Any chance the new "fatal" error for missing readiness includes could simply be downgraded to a logged warning? I would be perfectly happy in those environments to see a warning that REDIS readiness monitoring is not available.
Comment From: philwebb
Does setting management.endpoint.health.validate-group-membership to false as noted in the release notes fix your issue?
Comment From: quaff
@philwebb Could we make it default false to keep backward compatibility if it is not a security concern?
Comment From: philwebb
@quaff We've already shipped this so I don't think we should change it again. I think I prefer the default to be validating anyway, since then folks get the warning and need to choose to opt-out. Perhaps we can improve the error message to give a hint about management.endpoint.health.validate-group-membership.
Comment From: unluckypixie
Hi, Thanks yes setting that config option does fix my problem!
Sorry, I should have paid more attention to the release notes :o/
it is a shame to disable the validation, my ideal would be if there was some annotation I could use to dynamically included groups into the readiness probe.
My problem is solved though so feel free to close this one.
Comment From: scottfrederick
Reopening this issue to consider improving the error message when validation fails, as Phil suggested above. We could do this with a failure analyzer as is done for circular dependency validation.