Error

PRECONDITION_FAILED - inequivalent arg 'x-queue-type': classic and quorum queues in RabbitMQ

2026-10-19 · 3 min read · Viktor Baumann

One service declares the queue as a quorum queue, another one declares it without saying what type it is, and the second one fails:

PRECONDITION_FAILED - inequivalent arg 'x-queue-type' for queue 'orders' in vhost 'orders':
received 'classic' but current is 'quorum'

That is RabbitMQ 4.3.6's message. It shows up in two situations: two pieces of code that disagree about a queue, and a migration from classic to quorum queues.

What the error means

The type of a queue is fixed when it is created. A declaration without x-queue-type asks for a classic queue, so redeclaring an existing quorum queue without the argument is a mismatch, and RabbitMQ closes the channel. We measured both directions on 4.3.6:

Existing queue	Declared with	Result
quorum	no x-queue-type	PRECONDITION_FAILED, received 'classic'
classic	x-queue-type: classic	ok
classic	x-queue-type: quorum	PRECONDITION_FAILED, received 'quorum'

Code that disagrees

Every declaration of the queue has to state the same type. Typical sources of the classic declaration:

• an older service, a script or a test fixture that declares the queue with the client's defaults;
• a framework that declares queues it consumes from (Spring AMQP's Queue beans, MassTransit endpoints) where only one of the services sets the type.

Either add x-queue-type: quorum everywhere, or let only one place own the topology and have the others declare passively, which checks that the queue exists without comparing its arguments.

Moving a classic queue to quorum

The type of an existing queue cannot be changed in place. The way over that loses nothing:

1. Declare a new quorum queue under a new name (orders.q) and give it the same bindings as the old one.
2. Point the consumers at the new queue; publishers keep publishing to the exchange, so new messages now go to both queues.
3. Remove the old queue's bindings. It receives nothing more.
4. Move what is left in the old queue to the new one (a shovel, or "Move messages" in the management UI, which needs the shovel plugins enabled), then delete the old queue.

If the queue name is hard-coded in many places, the same steps work the other way round: drain the queue, delete it and recreate it as quorum under the same name, during a window in which nothing publishes to it.