Response messages for direct reply RPC show up as "Unroutable drop"

[luos]

Hi,

When there is a response message to the "pseudo-queue" amq.rabbitmq.reply-to.RANDOM-ID it is counted as an "Unroutable drop" message, which I think probably should not be the case.

The reason it happens because delivering of the message is done in the rabbit_exchange:route function, which then filters this target out, so the return value of route is an empty list.

https://github.com/rabbitmq/rabbitmq-server/blob/main/deps/rabbit/src/rabbit_exchange.erl#L405

Which then falls through to below because of the empty queue list:

https://github.com/rabbitmq/rabbitmq-server/blob/main/deps/rabbit/src/rabbit_channel.erl#L2166-L2173

Reproduction:

1. Consume from amq.rabbitmq.reply-to
2. Consume from a $QUEUE
3. Publish a message to $QUEUE with reply_to set to amq.rabbitmq.reply-to
4. Publish an answer to the message by publishing on the default exchange to the property reply_to of the received message
5. Observe the metric Unroutable drop on Grafana and Management

Sorry if this was already considered, I could not find an existing issue.

Thanks

[michaelklishin]

This is a known behavior but there are no specific suggestions as to what can be done. The routing code is unaware of the direct reply-to mechanism.

[michaelklishin]

For example, a new routing function with a clear name can be introduced, that would not track dropped messages, and be adopted exclusively by the Direct Reply To code path. A PR would be considered.

[gomoripeti]

Just for the record, somewhat similar is the case of publishing to a delayed-message-exchange which also returns an empty queue list from route/2, and it also increases unroutable-dropped count.
https://github.com/rabbitmq/rabbitmq-delayed-message-exchange/blob/main/src/rabbit_exchange_type_delayed_message.erl#L59

The difference is that it is not part of rabbit core, but a plugin exchange type, so it might require a different solution.