rabbitmq-dotnet-client icon indicating copy to clipboard operation
rabbitmq-dotnet-client copied to clipboard

Published 20 hours ago • verified publisher icon rabbitmq

Bug in topology-auto-recovery functionality

Open clooudch opened this issue 3 years ago • 3 comments

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

clooudch avatar Apr 09 '21 15:04 clooudch

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

michaelklishin avatar Apr 09 '21 18:04 michaelklishin

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

Jalalx avatar Aug 15 '21 07:08 Jalalx

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

bollhals avatar Aug 15 '21 20:08 bollhals

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

https://github.com/rabbitmq/rabbitmq-dotnet-client/pull/1460

lukebakken avatar Jan 04 '24 01:01 lukebakken

Setting milestone to 6.9.0, since this issue does not appear to be valid anymore in the 6.x branch - https://github.com/rabbitmq/rabbitmq-dotnet-client/pull/1465

lukebakken avatar Jan 08 '24 16:01 lukebakken