/api/aliveness-test/vhost uses deprecated feature transient_nonexcl_queues with RabbitMQ 4.0.x #13047
Milestone
Comments
|
Yes, we should change this. I guess a durable auto-delete queue should be the right choice for this purpose |
|
That health check arguably should be made a no-op because it is largely useless. There is no such thing as One True Health Check, we have made the CLI equivalent a no-op in |
|
I will make the check a no-op instead, it is already gone from the HTTP API reference in |
mergify bot
pushed a commit
that referenced
this issue
Jan 11, 2025
This follows the decision that was made for 'rabbitm-diagnostics node_health_check' which is a no-op as of 4.0.0 following a few years of deprecation. The justification is very similar: 1. There is no such thing as "One True Health Check". A single health check is too coarse-grained to explain what specifically is not right about cluster state 2. Indivual fine-grained health checks have been available for a few years now, see https://www.rabbitmq.com/docs/monitoring#health-checks 3. This particular check tests something that effectively never fails, based on my 14+ years of RabbitMQ contributions and user support of all shapes and forms 4. This check uses a deprecated feature: non-exclusive non-durable/transient classic queues If something about this health check is worth preserving, we can always add a new one under GET /api/health/checks/* Closes #13047. (cherry picked from commit ad906c9)
michaelklishin
added a commit
that referenced
this issue
Jan 12, 2025
This follows the decision that was made for 'rabbitm-diagnostics node_health_check' which is a no-op as of 4.0.0 following a few years of deprecation. The justification is very similar: 1. There is no such thing as "One True Health Check". A single health check is too coarse-grained to explain what specifically is not right about cluster state 2. Indivual fine-grained health checks have been available for a few years now, see https://www.rabbitmq.com/docs/monitoring#health-checks 3. This particular check tests something that effectively never fails, based on my 14+ years of RabbitMQ contributions and user support of all shapes and forms 4. This check uses a deprecated feature: non-exclusive non-durable/transient classic queues If something about this health check is worth preserving, we can always add a new one under GET /api/health/checks/* Closes #13047.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
In a fresh RabbitMQ 4.0.5 installation, when using the
/api/aliveness-test/%2FAPI call a queue namedaliveness-testis created in the corresponding vhost/. The queue is created as a classic, transient, non-exclusive queue. This leads to the "transient_nonexcl_queues" message withrabbitmqctl check_if_any_deprecated_features_are_usedand also in the management plugin to the message "Deprecated features are being used".Reproduction steps
rabbitmqctl check_if_any_deprecated_features_are_usedcurl -su user:password https://localhost:15671/api/aliveness-test/%2F{"status":"ok"}rabbitmqctl check_if_any_deprecated_features_are_usedExpected behavior
The API call
/api/aliveness-test/vhostmust not lead to the use of deprecated features.The text was updated successfully, but these errors were encountered: