Consumers

Who is draining the queues — and on what terms. The terms are the point: two of them are the reason a queue that looks healthy loses messages, and this screen names both.

What a row tells you

The consumer's tag, the queue it is subscribed to with the queue's type beneath it, where it connects from, its acknowledgement mode, its prefetch, and its status. The queue is a link — from "who is consuming" to "what they are consuming from" in one click. Its virtual host, its user and an exclusive marker are further columns under Columns.

The Vhost selector in the header scopes the list to one virtual host or to all of them, and the search box matches the tag, the queue, the virtual host, the user, the connection, the channel, the node and the peer address.

Above the table: how many consumers there are, how many distinct queues they serve, and how many are running without acknowledgements.

Auto-acknowledge is a hazard, not a mode

When a consumer subscribes with automatic acknowledgement, the broker forgets each message the moment it delivers it. If that consumer crashes mid-work, the message is gone — there is no redelivery, because as far as the broker is concerned it was already handled.

Unless it is reading a stream, where none of that is true. A stream retains its messages and a reader re-attaches at an offset, so "the message is gone" is simply the wrong sentence about it. BROKA reads each consumer's queue type and says the right thing for each: a stream reader is marked offset-based rather than warned about, its prefetch reads n/a, and it is not counted into the auto-acknowledge figure above the table. Where the queue type could not be read, the row shows a dash for it rather than assuming the classic case, and a note above the table says how many consumers were left out of the counts — the warning that fires on the wrong consumer is worth less than no warning at all.

BROKA marks the real cases twice: on the row, and as a counted figure above the table with the consequence spelled out. Manual acknowledgement gets a plain, unremarkable badge.

That asymmetry is deliberate. These are not two settings of equal standing that happen to differ; one of them silently converts a crash into data loss, and a console that presented them as equals would be withholding the only thing worth saying about the pair.

A prefetch of zero starves everything else

A consumer with no prefetch limit can be handed the whole queue before it acknowledges anything — which means every other consumer on that queue gets nothing while it works through the backlog.

It is marked on the row, and once on the page with the consequence named, so a screen with four such consumers does not become a wall of identical warnings.

A standby consumer is not a broken one

On a queue with single active consumer, only one consumer receives messages and the rest wait. BROKA shows a waiting consumer in its own colour — not a warning colour — and says it is idle by design.

That distinction exists because reading it as a fault is how an operator ends up restarting a healthy standby, which is the one action guaranteed to make the situation worse.

Broker plumbing looks different from applications

A shovel or a federation link consumes over a direct connection: it has no network peer and no user account. RabbitMQ reports those fields as placeholder text rather than leaving them empty, and BROKA translates that into what it means — internal — rather than printing the placeholder.

Showing undefined where an address belongs is worse than showing nothing.

Why nothing here can be cancelled

There is no action on this screen, and that is structural rather than an omission: RabbitMQ's management API has no remote consumer cancel. A consumer is cancelled by the client that registered it. The nearest thing an operator can do is close the whole connection, from the Connections screen.