passive queueDeclare resulting in 404, leaves channel open. about rabbitmq-server HOT 5 CLOSED

I have done some more investigation, it seems this problem, happens for all errors. And has existed since at least 2.6.

RabbitMQ sends a channel.close message, but it doesn't actually close the damn channel.

I have created an example of this here: https://gist.github.com/9fe5507c2e7169bb93b2

from rabbitmq-server.

This is a bug in all of the client libraries I have used.

When a server sends a channel.close, the client is expected to acknowledge with a channel.closeOk. If the client does this the channel is properly released.

from rabbitmq-server.

My reading of AMQP Spec is that no CloseOk is required when a channel is closed with an exception.
I would suggest this a bug in the server code?

https://www.rabbitmq.com/resources/specs/amqp0-9-1.pdf
2.2.3 No Confirmations
4.5 Channel Closure
The server will consider a channel closed when any of these happen:

1. Either peer closes the channel or the parent connection using a Close/Close-Ok handshake.
2. Either peer raises an exception on the channel or the parent connection

from rabbitmq-server.

Since this thread is from 2012, keep a couple of things in mind:

• Things could have changed since then.
• The AMQP 0-9-1 spec has known issues, inconsistencies and statements open to interpretation. Team RabbitMQ has an entire errata document. It also has features that 10 year later can confidently be considered poorly thought out and in a couple of places RabbitMQ deviates to do what's more user-friendly.
• If a particular behaviour is demonstrated by most popular client libraries, including those our team maintains, it is extremely unlikely that it's going to change by now. If something is a truly annoying behaviour, it has been reported plenty of times in the ~ 10 years since the 0-9-1 spec was last revised.

RabbitMQ sends clients a channel.close-ok in response to a channel.close, so why would clients not be required send a response when RabbitMQ initiates a close?

Anyhow, a quick glance at rabbit_channel/rabbit_reader, Java client and Bunny suggest that

• A channel.close-ok is still required.
• Java client and Bunny sent channel.close-ok as expected.
• In Java client it has been the case since at least Jan 2011 (very likely way earlier, it's just as early as things go for ChannelN in the current codebase)

So the reporter probably hasn't used one of the clients maintained by our team. node-amqp is known to be a terrible, buggy abandonware and we have been recommending avoiding it for years.
I cannot name a client that has caused more head scratching and false RabbitMQ bug accusations than node-amqp. Use amqp.node instead.

from rabbitmq-server.

Any further comments about how the spec should be interpreted belong to the mailing list.

from rabbitmq-server.