Fix/routing key to queue name

[pat-goins]

When republishing failed messages, publish to the _queueName the message came from instead of the message's routing key.

[ghost]

All CLA requirements met.

[JatinSanghvi]

@pat-goins - I debugged and found that both ea.routingKey and _queueName are set to same string. Did you encounter a case when the two differ?

[pat-goins]

@JatinSanghvi - yes, the case we ran into when ea.routingKey (pulled from the queue message) is not the same as _queueName (queue where the message was pulled from) is from messages published through the direct exchange with multiple bindings. This could be the case when messages are routed by means other than the default exchange.

For example, message routing could be setup like the scenario in the "Direct exchange" section from the RabbitMQ docs:

If a message errored while processing from queue Q1, it would have ea.routingKey of orange, but _queueName of Q1. Prior to this change, the CreateHeadersAndRepublish/RepublishMessages methods would republish the message on the default exchange with a routingKey of orange. This would result in the message going nowhere.

If the intent is for an errored message to go back to the queue it came from, it should be republished on the default exchange with the routingKey of the originating _queueName.

[pat-goins]

To workaround the issue, we are doing something like this first thing inside our queue triggered functions:

var originalRoutingKey = incomingMessage.RoutingKey;
incomingMessage.RoutingKey = Constants.Queues.AuditQueueName;

[JatinSanghvi]

Hi @pat-goins , thanks for the detailed explanation. I agree it makes sense to republish failed messages to default exchange with queue-name as the routing key. I should come back to the PR next week. Need to set some time to reproduce the error and verify your fix, and read on if there are any other alternate retry options (I doubt though) that works well with multiple bindings in place.

[JatinSanghvi]

Thanks @pat-goins 👍 I have merged the PR changes.