Precondition fails for existing queue due to new queue options

[arthurmde]

Version: 0.28.0

PR #341 may have broken existing consumers due to Precondition Failed:

Channel#handle_frame on channel 1: #<AMQ::Protocol::Channel::Close:0x00005620761905b8 @reply_code=406, @reply_text="PRECONDITION_FAILED - inequivalent arg 'x-queue-mode' for queue 'estimate_accepted_consumer' in vhost '/': received the value 'default' of type 'longstr' but current is none", @class_id=50, @method_id=10

It seems that the 'default' value isn't the real default value for the x-queue-mode option. Existing queues did not have value for this option and that's failing the Predocation Validation.

I can fix this, but I have some questions though:

• How can someone update the options of an existing queue?
  • If it is not possible, we should change the Consumer class to not send this option unless it is explicitly set through lazy_queue method
  • If it is possible, shouldn't Hutch always be responsible for updating the queue arguments whenever it loads the consumer?

We may have the same problem for x-queue-type option

[michaelklishin]

All of these are answered in the RabbitMQ Queues guide. Hutch cannot "update" queue properties as there is no such feature in the protocol. Some optional properties can be controlled via policies. Nothing specific to Hutch.

As for #341, see https://github.com/rabbitmq/rabbitmq-common/issues/341. RabbitMQ will treat a missing queue type parameter as identical to x-queue-type: classic as of 3.8.2.

[arthurmde]

Nice. Thanks for answering.

I will apply policies to my queues.

Nevertheless, I think it would be good to have something similar to rabbitmq/rabbitmq-common#341 to treat a missing queue mode as identical to and x-queue-mode: default value