requeue option of the Get Messages UI is ignored about rabbitmq-management

[michaelklishin]

Looking at the code, it seems that "no requeue" is treated slightly differently from what you expect:

NoAck = not rabbit_mgmt_util:parse_bool(RequeueBin),

and then

basic_get(Ch, Q, NoAck, Enc, Trunc) ->
    case amqp_channel:call(Ch, #'basic.get'{queue = Q,
                                            no_ack = NoAck}) of
        {#'basic.get_ok'{redelivered   = Redelivered,
                         exchange      = Exchange,
                         routing_key   = RoutingKey,
                         message_count = MessageCount},
         #amqp_msg{props = Props, payload = Payload}} ->
            [{payload_bytes, size(Payload)},
             {redelivered,   Redelivered},
             {exchange,      Exchange},
             {routing_key,   RoutingKey},
             {message_count, MessageCount},
             {properties,    rabbit_mgmt_format:basic_properties(Props)}] ++
                payload_part(maybe_truncate(Payload, Trunc), Enc);
        #'basic.get_empty'{} ->
            none
    end.

It other words, it is used as the noack argument to basic.get but nothing else as far as I can tell.

[Gsantomaggio]

As @michaelklishin wrote, requeue value is used as noack for basic.get .

Basically it is different the meaning of requeue.

To use requeue option we could set no_ack = false and then use basic.reject as:

basic_get(Ch, Q, Requeue, Enc, Trunc) ->
    case amqp_channel:call(Ch, #'basic.get'{queue = Q,
                                            no_ack = false}) of
        {#'basic.get_ok'{redelivered   = Redelivered,
                         exchange      = Exchange,
                         routing_key   = RoutingKey,
                         message_count = MessageCount,
                         delivery_tag  = DeliveryTag},

         #amqp_msg{props = Props, payload = Payload}} ->
         amqp_channel:call(Ch, #'basic.reject'{delivery_tag = DeliveryTag,
                                            requeue = Requeue}),
            [{payload_bytes, size(Payload)},
             {redelivered,   Redelivered},
             {exchange,      Exchange},
             {routing_key,   RoutingKey},
             {message_count, MessageCount},
             {properties,    rabbit_mgmt_format:basic_properties(Props)}] ++
                payload_part(maybe_truncate(Payload, Trunc), Enc);

In this case the when you set requeue = false the message will be redirect to the dead letter exchange (if you have one)

[Gsantomaggio]

To be more generic we could modify the requeue with something like this:
<select name="requeue">
<option value="ack">Ack message </option>
<option value="nack">NAck message </option>
<option value="reject_false">Reject requeue false</option>
<option value="reject_true">Reject requeue true</option>
</select>

See the image here

[Gsantomaggio]

The branch rabbitmq-management-68 contains the new Get Message(s).

UI options:

I had to change the requeue=yes/no API with:

ackmode=ack_requeue_false
ackmode=ack_requeue_true
ackmode=reject_requeue_false
ackmode=reject_requeue_true 

So, we have more options, but we lose the API compatibility.

[michaelklishin]

@Gsantomaggio that's fine, then it should go into 3.7.0.

[yzharko]

@Gsantomaggio that's fine, then it should go into 3.7.0.

It's not fine. I spend 40 minutes to find all possible options list

[lukebakken]

@Yegos - could you elaborate on the trouble you had by posting a message to rabbitmq-users? Please be sure to let us know what version of RabbitMQ and Erlang you're using.

[michaelklishin]

@Yegos what I meant by "fine" is that a feature release in our case allows for breaking changes. We updated HTTP API clients that we maintain as well as rabbitmqadmin to match.

I see that the docs in the HTTP API reference do mention all possible values in the /api/queues/{vhost}/{name}/get endpoint description. All of our docs are open source and the entire core team is on our mailing list, so your PRs and feedback on the docs is always welcome.

[michaelklishin]

RabbitMQ 3.7.0 release notes do mention breaking changes in the HTTP API. I added a note in bold next to this specific issue to mention that the request body expected from the client has changed.

If you have other ideas as to what can be improved, they are welcome on the list. FWIW RabbitMQ 3.7.0 has shipped 1 year ago, so at this point it's on library and tool authors who haven't caught up with the changes.