Bug in topology-auto-recovery functionality

[clooudch]

Hello there

I think I found a bug in the rabbitmq-dotnet-client with the topology-auto-recovery functionality.

How it can be reproduced:

• create a connection with topology-auto-recovery enabled
• open a channel
• create an exchange, an exclusive queue and a binding to it
• dispose the created channel
• open another channel
• recreate the exchange, the queue and the binding
• consume from the queue
• force close the connection with rabbit mq management plugin
• wait until auto-recovery kicks in and restores the connection, channel and topology
• binding to the queue is lost

While this issue can be best reproduced with an exclusive queue, it actually affects all bindings.

What's the cause of this:

1. While recordings for other topology entities are updated, this is not the case for bindings (see: source code, where HashSet.Add does not overwrite the recorded entity) -> please consider updating the recordings also for the bindings and not only for other topology entities.
2. I think the actual root cause is, that the AutorecoveringConnection stores disposed instances of AutorecoveringModel. I would suggest that when a AutorecoveringModel instance is disposed, that also all the recorded topology entities on the connection get cleaned up. This would completely avoid this issue and also potential other issues.

Kind regards
clooudch

[michaelklishin]

This is open source software, so you are welcome to contribute code changes instead of asking others to do it.

[Jalalx]

@clooudch Can you please provide a reproducible code in a repo or somewhere?

[bollhals]

This is very likely related to #1061. (Creating bindings on a channel that gets disposed and later a reconnect is happening

[lukebakken]

Hey everyone, I added the following PR with a test that demonstrates (I think) that bindings are restored correctly:

#1460

[lukebakken]

Setting milestone to 6.9.0, since this issue does not appear to be valid anymore in the 6.x branch - #1465