The meaning of "running" in the queue state column

[voicerecordist]

Describe the bug

i deploy rabbitmq with official community image
(RabbitMQ 4.0.2 Erlang 26.2.5.4)

in queues tab, all states are running:

but in queue details, it shows idle(and it really is):

Even if I create a new queue, its status is displayed as "Running".

I have Durable classic or quorum queues and auto-delete is disable for all queues.

Are there any special settings or tips or just a bug?

Reproduction steps

1.open dashboard
2.in Queues and Streams tab you see all tab running
3.but in queue page it could be idle
...

Expected behavior

i want in both page show me the correct status

Additional context

No response

[michaelklishin]

@voicerecordist please never again use issues for questions. GitHub has had Discussions for a few years now.

The metric in question has nothing to do with queue properties and everything to do with the definition of a "running" or "idle" or "flow" (experiencing transient flow control).

Historically classic queues were considered "running" when the replica Erlang process had any activity other than hibernating in the last N seconds. The usefulness of this is limited because
queues emit metrics as often as the management UI updates by default (every 5 seconds),
therefore you will in practice see queues to be running even if they are not accepting routed
messages and not delivering them. Metric emission is also an activity.

For quorum queues, the definition is the following:

-spec cluster_state(Name :: atom()) -> 'down' | 'recovering' | 'running'.

cluster_state(Name) ->
    case whereis(Name) of
        undefined -> down;
        _ ->
            case ets:lookup_element(ra_state, Name, 2, undefined) of
                recover ->
                    recovering;
                _ ->
                    running
            end
    end.

In other words, if a quorum queue is not recovering, it is considered to be running.
There is nothing inherently wrong with this definition, it simply tells you the the queue
leader is not down and is not recovering its on disk log after a node restart.

For streams, it is

i(state, Q) when ?is_amqqueue(Q) ->
    %% TODO the coordinator should answer this, I guess??
    running;

If someone cares enough about this value, here is where you can contribute an improvement. So far in several years of stream existence no one has cared enough.

A better question to ask is: how do you decide if a queue is "active" or not. The answer is: not using those labels which simply help you spot when something is off with the queues.

The right approach is to use relevant metrics, which are much more nuanced are won't be affected by stats emission activity.

That docs table arguably needs to list a different set of consumer metrics because polling consumers are highly recommended against but it does refer you to the relevant HTTP API endpoint.

All of those metrics are available in the management UI (unless you hide them), and the Prometheus scraper endpoint. Use those metrics to determine if a queue is "active" or not, not the "state" column because during normal operations it is not particularly useful. But it's been there since 2010 and removing may or may not be well received.

[michaelklishin]

Speaking of metrics, this is the kind of metrics our team considers worth spending time on #13107.

The "state" column? Not so much, no one really pays attention to it during normal cluster operation.