rabbitmqctl cluster_status with json formatter has broken output for running_nodes

[noonedeadpunk]

Describe the bug

In RabbitMQ 4.1.2 output of rabbitmqctl cluster_status --formatter json | jq ".running_nodes" returns a string without any separation rather then a list, like it does for disk_nodes for example:

# rabbitmqctl cluster_status --formatter json | jq ".running_nodes"
"rabbit@rabbitmq02rabbit@rabbitmq01rabbit@rabbitmq03"
# rabbitmqctl cluster_status --formatter json | jq ".disk_nodes"
[
  "rabbit@rabbitmq01",
  "rabbit@rabbitmq02",
  "rabbit@rabbitmq03"
]

This used to work for us in 4.0.9 at very least.

With that, output a formater (table) or erlang is rendering normally:

Disk Nodes

rabbit@rabbitmq01
rabbit@rabbitmq02
rabbit@rabbitmq03

Running Nodes

rabbit@rabbitmq01
rabbit@rabbitmq02
rabbit@rabbitmq03

# rabbitmqctl cluster_status --formatter erlang
Cluster status of node rabbit@rabbitmq03 ...
[{nodes,[{disc,[rabbit@rabbitmq01,rabbit@rabbitmq02,rabbit@rabbitmq03]}]},
 {running_nodes,[rabbit@rabbitmq02,rabbit@rabbitmq01,rabbit@rabbitmq03]},
 {cluster_name,<<"rabbitmq_cluster1">>},
 {partitions,[]},
 {cluster_tags,[]},
 {alarms,
     [{rabbit@rabbitmq03,[]},{rabbit@rabbitmq02,[]},{rabbit@rabbitmq01,[]}]},

Reproduction steps

1. rabbitmqctl cluster_status --formatter json | jq ".running_nodes"

Expected behavior

[
  "rabbit@rabbitmq01",
  "rabbit@rabbitmq02",
  "rabbit@rabbitmq03"
]

Additional context

Running following versions:

• erlang 27.3.4.2
• rabbitmq 4.1.2
• OS: Debian 12 / Ubuntu 24.04 / CentOS Stream 10

[michaelklishin]

@noonedeadpunk you must have missed #14381.

I'd argue that no one needs to parse cluster_status output to get the list of cluster nodes, an HTTP API endpoint that does the same thing and only supports JSON output has been available for some 15 years now.

[noonedeadpunk]

Ah, thanks for pointing out. As I've checked just 4.1.3 release notes, but what was merged after the release - my bad.

Regarding API - I guess I indeed can fetch most of the data from this API, just in quite more complex way (at least from a quick evaluation), and then get list of Feature Flags from a separate request, while also maintaining an administrative credentials in script...
But to be frank - rabbitmqctl still looks way more appealing to deal with just because it has a very nice excerpt of parameters you might need to check with a minimal overhead (from operator perspective).

Anyway, thanks a ton for replying and already fixing the issue!

[michaelklishin]

Nothing in the RabbitMQ HTTP API, client libraries or tools such as rabbitmqadmin v2 requires hardcoding credentials into a script.

They can come from an environment variable, a secret store such as Vault or 1Password, or an operator-provided command line argument, including an encrypted value you will decrypt only before using.