How can I get all messages headers in a queue?

[TheUnableDeveloper]

Is your feature request related to a problem? Please describe.

Hello,
I'm trying to get the list of enqueued messages in a queue.
I see that the API doesn't support this functionality.

Describe the solution you'd like

I'd like to have a new API route to get the list of headers of the messages in a specific queue,
with all the related statuses (ACK true/false, etc)

thanks!

Describe alternatives you've considered

No response

Additional context

No response

[mkuratczyk]

Please elaborate on your request. The way it sounds right now suggest that you are trying to use a queue for something that you shouldn't use a queue for. Why do you need it? Are you building a management console and you want a "browse a queue" functionality or what?

Quorum queues support messaging peek. Perhaps that's good enough?

> rabbitmq-queues peek qq 1
Peeking at quorum queue qq at position 1 on node rabbit@K6L59PF0JR ...
┌─────────────────────────┬──────────────────────────────────────┐
│ keys                    │ values                               │
├─────────────────────────┼──────────────────────────────────────┤
│ delivery_mode           │ 2                                    │
├─────────────────────────┼──────────────────────────────────────┤
│ routing_keys            │ 51e01da2-041f-439b-86aa-b335b8439630 │
├─────────────────────────┼──────────────────────────────────────┤
│ exchange                │ direct                               │
├─────────────────────────┼──────────────────────────────────────┤
│ payload (max 64 bytes)  │ <<0,0,0,0,0,0,1,148,95,204,12,54>>   │
├─────────────────────────┼──────────────────────────────────────┤
│ header.x-delivery-count │ 0                                    │
└─────────────────────────┴──────────────────────────────────────┘

[mkuratczyk]

Are you referring to this discussion?
noxdafox/rabbitmq-message-deduplication#27 (comment)

The issue mentioned still applies and there are more issues with this approach. Messages can be requeued, you will have race conditions between the moment you check for the status of the message and the moment you decide to allow the second one, the performance would be terrible...

You need a different solution to your problem. Checking the status of an in-flight message (let alone checking the status of all the messages in the queue, given there could be millions) to decide whether the next message should be allowed into the queue is just not viable.

We can try to assist you with a different solution, but please describe the problem, not the solution you have in mind. I still don't understand why you'd want a message to be rejected or not, based on whether a similar message has been acknowledged or not.
Ideally, your message processing should be idempotent. You can set some value in the message and ignore duplicates in your consumer for example. Then, I believe, your problem would just go away.

[michaelklishin]

There is no such state as "in progress" in RabbitMQ. The states are: ready (to be delivered), delivered (but yet unacknowledged), acknowledged (marked for deletion), or requeued (back to the ready state with some metadata changes).

We will not support the message de-duplication plugin in any way. Use streams which support deduplication, we will not provide any support 3rd party plugins.

[TheUnableDeveloper]

Clarification and Context
When I mentioned "in progress," I actually meant "delivered but yet unacknowledged." In this scenario, I'd like the ability to add a new message, regardless of whether it has the same ID.

I don’t require official support for a third-party plugin, and I cannot use streams or quorum queues since they are not compatible with this plugin (only classic queues are supported).

My Requirement
Every time an event is triggered in the API (producer), clients connected via sockets should receive a refresh message.

The API produces this refresh message, and a consumer sends a corresponding refresh event to the sockets.
Multiple events with the same ID might occur in a short period, but I don’t need all of them to be delivered. Ideally, just one message is sufficient, so the others could be discarded.
However, if the first message takes too long to process and another one arrives, it would be beneficial to keep the latest message instead of discarding it (because otherwise it would be like missing a refresh)

I think I'll try to keep track of the messages that I publish

thank you!
and sorry for my confused messages

[michaelklishin]

RabbitMQ does not prevent you from publishing to a queue that has undelivered messages. It does not verify or force message uniqueness. Publishers can set an ID in message properties but it is only there for applications to use however they see fit.

If you need a deduplication, use a stream. If you need only one messages to be processed at a time from a given publisher, that's a publisher and consumer coordination problem, RabbitMQ does not "take back" deliveries from consumers.

Consumers themselves should cancel any tasks they have in progress when a newer message from the same publisher arrives.