Topology Recovery error on Server restart: operation queue.bind caused a channel exception not_found: no queue in vhost

[Dash83UPV]

Dear all

I have been testing the Topology Recovery on network fails and broker restart.

Goal of the Test: Bidirectional communications from Client A to Client B. The communication recovers. At the moment the messages do not have importance.

---

VERSIONS

Server: RabbitMQ 3.11.12 + Erlang 25.3 (just installed on ubuntu server minimal)
Client: c# library version 6.4.0 (.NET 4.72)

---

TESTING

Only one client

1. Opened 2 connection to the Server. One for Tx, one for Rx. (Automatic connections and topology recovery enabled on both)

2. Open 2 channels (one for Tx + one for Rx)

3. Create Exchange A type Direct.
   3.1) Create Queue B (non-durable, no exclusive, no auto-delete)
   3.2) Bind Queue B to Exchange A with routing key B

4. Create Queue A (non-durable, no exclusive, no auto-delete)
   4.1) Basic Consumer (subscribe) to Queue A

5. Send message to Queue B.

6. During normal operation everything works correctly.

7. First test: Network failure. --> Both connections recover perfectly

8. Second test: Server restart --> Sometimes they recover perfectly. Other times the connections fails and I get the following logs on the server

In the case of the Exchange Binding

2023-03-31 11:39:54.679680+00:00 [info] <0.667.0> accepting AMQP connection <0.667.0> (172.16.200.3:61549 -> 192.168.30.122:5672)
2023-03-31 11:39:54.724980+00:00 [info] <0.667.0> connection <0.667.0> (172.16.200.3:61549 -> 192.168.30.122:5672) has a client-provided name: app:XXXX component:test-A-B-Tx
2023-03-31 11:39:54.726701+00:00 [info] <0.667.0> connection <0.667.0> (172.16.200.3:61549 -> 192.168.30.122:5672 - app:XXXX component:test-A-B-Tx): user 'XXXX' authenticated and granted access to vhost 'XXXX'
2023-03-31 11:39:54.728913+00:00 [error] <0.689.0> Channel error on connection <0.667.0> (172.16.200.3:61549 -> 192.168.30.122:5672, vhost: 'XXXX', user: 'XXXX'), channel 1:
2023-03-31 11:39:54.728913+00:00 [error] <0.689.0> operation queue.bind caused a channel exception not_found: no queue 'B' in vhost 'XXXX'
2023-03-31 11:39:54.732347+00:00 [info] <0.667.0> closing AMQP connection <0.667.0> (172.16.200.3:61549 -> 192.168.30.122:5672 - app:XXXX component:test-A-B-Tx, vhost: 'XXXX', user: 'XXXX')

In case of the Consumer Binding

2023-03-31 11:39:54.680335+00:00 [info] <0.670.0> accepting AMQP connection <0.670.0> (172.16.200.3:61550 -> 192.168.30.122:5672)
2023-03-31 11:39:54.724717+00:00 [info] <0.670.0> connection <0.670.0> (172.16.200.3:61550 -> 192.168.30.122:5672) has a client-provided name: app:XXXX component:test-A-B-Rx
2023-03-31 11:39:54.726385+00:00 [info] <0.670.0> connection <0.670.0> (172.16.200.3:61550 -> 192.168.30.122:5672 - app:XXXX component:test-A-B-Rx): user 'XXXX' authenticated and granted access to vhost 'XXXX'
2023-03-31 11:39:54.729183+00:00 [error] <0.696.0> Channel error on connection <0.670.0> (172.16.200.3:61550 -> 192.168.30.122:5672, vhost: 'XXXX', user: 'XXXX'), channel 1:
2023-03-31 11:39:54.729183+00:00 [error] <0.696.0> operation basic.consume caused a channel exception not_found: no queue 'A' in vhost 'XXXX'
2023-03-31 11:39:54.732663+00:00 [info] <0.670.0> closing AMQP connection <0.670.0> (172.16.200.3:61550 -> 192.168.30.122:5672 - app:XXXX component:test-A-B-Rx, vhost: 'XXXX', user: 'XXXX')

---

DIAGNOSTICS

For what I understand, the Topology Recovery algorithm tries to re-bind (queue B) or re-subscribe (queue A) a queue that it not there yet, then it generates and exception, the recovery process fails and the connection is dropped.

I can bypass the issue by making both queues (A & B) durable. Then they will survive a server restart and problems solves, BUT...
I do not want to make them durable just for that.

---

QUESTIONS

So my questions are:

1. Am I doing something wrong?
2. Is there a bug on the recovery algorithm that should be addressed?
3. Was the option to recover an non-durable queue never an intended feature?
4. Any other ideas on how to solve the issue?

By the way I have event listener on all steps of the process to catch at client side as much information as possible.

conn.ConnectionShutdown += Conn_ConnectionShutdown;
conn.RecoverySucceeded += CommManager_RecoverySucceeded;
conn.ConnectionRecoveryError += Conn_ConnectionRecoveryError;

Should the test code be requires I can upload it.

Thank you for your help and best regards.