The channel is unpredictably closed.

[dormanze]

Hello, everybody.
I have a temporary exclusive queue that consumes messages using manual ack. After the node where the queue is located is powered off, some messages are still being consumed by the consumer. After the messages are consumed, the consumer sends an ACK message to the server. In this case, the ACK message reports an error. As a result, my public channel is forcibly closed, affecting other consumers.
I want to know why the channel is forcibly closed if the ack message ID is incorrect or a queue does not exist. This seems to be done by the server. Also, I'd like to know if there's some configuration to ignore these non-existent message IDs and not force the channel to be closed.

[michaelklishin]

That's how the protocol was designed.

There are two highly relevant documentation sections.

• Channel exceptions
• Most common acknowledgement errors

[michaelklishin]

Ask yourself what else the server could do when you try to consume from a non-existent queue or acknowledge an unknown delivery tag (which includes double acknowledgements). It should probably communicate an error somehow to the client. And since messaging protocols are usually asynchronous in nature (many operations do not have a direct response associated with them), this is basically how an error is communicated: by closing the channel. It's not the only approach but many messaging protocols have independently settled on something quite similar to this behavior.

If you know that it makes sense to retry, you can open a new channel and do just that.