RabbitMQ - upgraded to a new version and got a lot of "PRECONDITION_FAILED unknown delivery tag 1"

Question

Just upgraded to a new version of RabbitMQ -- 2.3.1 -- and now the following error occurs:

PRECONDITION_FAILED unknown delivery tag 1  

...followed by the channel closing. This worked on an older RabbitMQ with no client-side changes.

---

In terms of application behavior:

When App A wants to send an async message to App b and receive an answer from B, this is the algorithm:

1. App A generate a unique ID and puts it in the message object
2. Then App A subscribes to a new Queue with both the queue name and routing key equals to the uuid.
3. App B open the message, do some calculations and return the result to the channel with the routkey that it recieved.
4. App A gets the answer and close the queue.

So far everything went really well in 1.7.0. what went wrong in 2.3.1?

---

When Application A calls basicPublish(), application B immediately throws the following exception:

com.rabbitmq.client.ShutdownSignalException: channel error; reason: {#method<channel.close>(reply-code=406,reply-text=PRECONDITION_FAILED - unknown delivery tag 1,class-id=60,method-id=80),null,""}
    at com.rabbitmq.client.impl.ChannelN.processAsync(ChannelN.java:191)
    at com.rabbitmq.client.impl.AMQChannel.handleCompleteInboundCommand(AMQChannel.java:159)
    at com.rabbitmq.client.impl.AMQChannel.handleFrame(AMQChannel.java:110)
    at com.rabbitmq.client.impl.AMQConnection$MainLoop.run(AMQConnection.java:438)
Caused by: com.rabbitmq.client.ShutdownSignalException: channel error; reason: {#method<channel.close>(reply-code=406,reply-text=PRECONDITION_FAILED - unknown delivery tag 1,class-id=60,method-id=80),null,""}

Answer 1

The only codepath that can cause that exception is through the broker handling a 'basic.ack', so this sounds like a client issue; check the client code.

In particular, check that you aren't ack'ing messages more than once. Doing so is in violation of the AMQP 0-9-1 spec:

A message MUST not be acknowledged more than once. The receiving peer MUST validate that a non-zero delivery-tag refers to a delivered message, and raise a channel exception if this is not the case

A great place to ask such questions is the rabbitmq-discuss mainling-list; all the RabbitMQ developers read that list and make a point of not leaving questions unanswered.

It's also worth noting that previous versions of Rabbit were more lax and did not throw an error in this case, but more recent versions do.

Answer 2

Just set noAck: false on BasicConsume method