RabbitMQ Health Checks cannot be disabled from 3.7+

[bcluap]

Describe the bug

mp.messaging.incoming.XXX.health-enabled=false removes the channel from the health check data, but even if there is only one channel and its health is turned off, it will fail the health checks if rabbit cannot be connected

e.g.
{
"name": "SmallRye Reactive Messaging - readiness check",
"status": "DOWN",
"data": {
"application-com.ukheshe.services.banknodescantopay.BanknodeScanToPayBankReplyListener#consume": "[KO] - Connection refused"
}
}

Also,
quarkus.health.extensions.enabled=false
Used to completely disable reactive messaging health checks on <=3.6 but from 3.7 onwards it does not disable the health checks.

Expected behavior

If all channels have health disabled then completely disable health checks for reactive messaging

if quarkus.health.extensions.enabled=false then completely disable health checks for reactive messaging

Actual behavior

As per bug description

How to Reproduce?

No response

Output of uname -a or ver

No response

Output of java -version

No response

Quarkus version or git rev

No response

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response

[quarkus-bot]

/cc @cescoffier (reactive-messaging), @jmartisk (health), @ozangunalp (reactive-messaging), @xstefank (health)

[metacosm]

Indeed, there doesn't seem to be a way to deactivate the probes altogether anymore. In particular, probes will also always be output in generated manifests even if the health extensions are disabled.

[bcluap]

As a workaround I've configured like this so that the reconnects happen forever (pretty much) and it doesn't go into an unhealthy state after 100 attempts 10 seconds apart (which is the default):
mp.messaging.incoming.XXX.health-enabled=false
mp.messaging.incoming.XXX.reconnect-attempts=9999999
mp.messaging.incoming.XXX.reconnect-interval=30

[xstefank]

Probably same as #38329

[cescoffier]

@xstefank #38329 was about all connectors, and I closed it as it was working correctly for Kafka and AMQP. But I didn't try RabbitMQ. The RabbitMQ connector is not at the same level, and I rewrote the health checks last December.

[ozangunalp]

There may be multiple issues in play here. The health probe notifies the KO not from the specific channel but from the framework itself. Reactive messaging gathers application errors and includes them in the health probes, that's why the data starts with application-.
@cescoffier I'll check the recent changes we did in rabbitmq connector.
Nevertheless, the quarkus.health.extensions.enabled=false not working is not related to this.

[ozangunalp]

At first look, neither quarkus.health.extensions.enabled nor quarkus.reactive-messaging.health.enabled work because since this change we started to include health check beans automatically inside the jandex index.
We can revert that change to begin with.