[Questions] Different handling of empty routing key binding in 4.3.0

[Ergamon]

Community Support Policy

• I have read RabbitMQ's Community Support Policy

RabbitMQ version used

4.2.x

How is RabbitMQ deployed?

Community Docker image

Steps to reproduce the behavior in question

I have upgradet from 4.2.5 to 4.3.0 and experienced a strange behavior.

We have a pub/sub scenario where the publisher is sending messages to an exchange with a routing key "" (empty string).

The subscriber is creating a queue and binding it to the exchange also with the empty string as routing key.

In all versions up to 4.3.0 this works.

Since the update to 4.3.0 the subscriber now gets all messages with an empty string routing key, even the ones from other exchanges not bound to the queue.

When I change the subscriber binding to "#", the false messages do not end in the queue. Basically everything works as in older versions.

This is a very confusing behavior from my perspective. I have a publisher writing to exchange1 and a subscriber listening to exchange2, but getting the messages.

I did not find anything about this in the changelog.

Is this an intented behavior or a bug?

[michaelklishin]

Subscribers do not "listen on exchanges", the separation of exchanges and queues is RabbitMQ 101.

@Ergamon you don't have any examples but if we are talking topic exchanges, using "" to say "route everything" worked by accident. Use a fanout exchange or at least "#" (which is a less efficient way of simulating a fanout exchange with a topic one).

[michaelklishin]

RabbitMQ topic exchanges route using a data structure called trie (not to be confused with "tree") created from the binding time routing key using the . segment separator.

An empty routing key is a trie with just one node, the root. Topic exchanges were never supposed to be used that way.

When topic exchange binding storage and use with Khepri was refactored in 51f7157, #15619 #15974, this specific scenario was not considered.

I refuse to consider this a regression, the way your topology is set up is not reasonable and is not covered by any tests (in RabbitMQ or any of the dozens of client libraries, 19 years later), and therefore it worked by accident prior to #15619.

[ansd]

Is this an intented behavior or a bug?

This is a bug that needs to be fixed.
Work in progress in #16271

[ansd]

Closed this discussion since the PR is ready for review.