Channels that have had exceptions but not explicitly closed can be recovered via connection recovery

[lukebakken]

Describe the bug

Reported here: https://groups.google.com/g/rabbitmq-users/c/lhLt0pkCFv4

---

Observed the following and wondering if it is expected or considered to be a possible issue.

Using Java 5.13.1 rabbitmq client library against RabbitMQ 3.11.18 Erlang 25.3.2.2 cluster.

Testing several recovery scenarios, specifically the documented behavior "Channel-level exceptions will not trigger any kind of recovery as they usually indicate a semantic issue in the application (e.g. an attempt to consume from a non-existent queue)."

In my test:

• Allocate auto-recovering connection
• Allocate channel from the connection
• basicConsume() from a busy queue
• Deliberately app-error the channel closed so it won't autorecover (in my case I called basicAck() with an invalid msg id on the channel)
• As expected, consumption stops, incoming events to the queue do not fire consumer callbacks

What surprised me:

With my app in the above state, in the Rabbit UI, I performed a "Force Close" of the connection. When the connection recovered, it also recovered the channel and consumer callbacks started firing again with new events.

I had not explicitly closed the channel after the application error since I assumed it to be closed "underneath" me, and it did not recover as long as its parent connection remained stable. But when the parent connection was forced to recover it did recover the channel closed by protocol error which seems to go against the documentation.

Reproduction steps

See above.

Expected behavior

The documentation should be changed to reflect this edge case.

Additional context

No response