Allow update of RoutingKey during Nack

[roddharris]

Is your feature request related to a problem? Please describe.

Currently, it is pretty easy to set up a retry mechanism using dead-letter (DL) queues with TTL.

However, I'd like to set up something a bit more robust whereby a message is dead-lettered the first 5 times to a queue that has a TTL of 10 seconds. After 5 attempts (using the count in x-death), I would then like to have the dead-lettered message redirect to a different queue that has a TTL of 30 seconds or 1 minute.

As far as I can tell, the current framework really only allows you to DL to a single queue.

Describe the solution you'd like

With my current DL setup, I have a topic Exchange that routes to the incoming queue based on the routing key. When dead-lettering, I'm not overriding the routing-key so that when the dead-letter message times out of the DL queue, it will route back to the correct incoming queue.

If I could manipulate the routing key when Nack-ing the message, I could append a special key to control where the message would dead-letter.

For example, given two topic Exchanges:
Incoming_Exchange
Retry_Exchange

and 4 queues:
Test_Incoming (bound to Incoming_Exchange with routing key test.sm.#)
ShortRetry (bound to Retry_Exchange with routing key test.sm.#.@Retry1 and TTL 5000 with DL back to Incoming_Exchange)
LongRetry (bound to Retry_Exchange with routing key test.sm.#.@retry2 and TTL 60000 with DL back to Incoming_Exchange)
FinalDL (bound to Retry_Exchange with routing key test.sm.#.@Final with no TTL)

Calling consumer.Model.BasicReject(deliveryTag, false, originalRouting + ".@retry2") would enable me to control which DL queue the message would be routed to.

Describe alternatives you've considered

The BasicReject() method seems to me to be the cleanest place to do this but I'm open to other options.

Additional context

Thanks for the consideration.

[michaelklishin]

Both protocol operations that nack deliveries do not have a field for routing key, and their goal is clearly not to update the topology or modify the message. RabbitMQ very rarely update message metadata and never the primary routing key (although new ones can be added). I'm afraid we will not change the protocol over this.

Projects such as NServiceBus support "staged" dead-lettering based on TTL. This is a pretty standard practice as far as I can tell.

[michaelklishin]

As far as changing the routing key of the delivery itself, a channel interceptor plugin would be able to do something like that based on the redelivery count. Similarly to how rabbitmq-routing-node-stamp and friends update messages.

Plugins have access to the topology via the schema database. I suspect such plugin would have to use a convention for queue and routing key naming.