Nacking after republishing with DLQ configured via policy

Hello,

I have weird behavior when using the dead-letter-exchange policy and republish strategy together.

I created a queue using the config:

    vhosts: {
        '/': {
            connection: {
                url: config.get('messageBus')?.url,
                options: {
                    heartbeat: 1,
                },
                socketOptions: {
                    timeout: 5000,
                },
                retry: {
                    factor: 2,
                    strategy: 'exponential',
                    delay: 1000,
                    max: 10,
                },
            },
            exchanges: ['exchange', 'dead-letters-exchange'],
            queues: {
                'queue': {},
                'dead-letters-queue': {},
            },
            bindings: [
                'exchange[key] -> queue',
                'dead-letters-exchange[key] -> dead-letters-queue',
            ],
            ///.....
        },
    }

To avoid complex redeployments I decided to configure dead letter exchange using policy:

Pattern | queue
dead-letter-exchange: dead-letters-exchange

Issue:

And when I do the nacking with the default strategy or with { strategy: 'nack' } it works, and I can see message in the dead-letters-queue.

But when I use this configuration:

const RECOVERY_STRATEGY: Recovery[] = [{ strategy: 'republish', defer: 15000, attempts: 3 }, { strategy: 'nack' }];

ackOrNack(err, RECOVERY_STRATEGY);

It retries 3 times and the message just disappears. Could you please take a look? Maybe I’m missing something or can help to fix this by contributing.

Thank you in advance!

[cressie176]

How can I set up the DLQ login in this case if I have multiple routing keys and different queues per key?

I think you will need to bind each DLQ twice. Once with the routing key, and once with the queue name. That way if the message is nacked by your application before being republished, or times out due to a message-ttl, it will be routed to the dead letter exchange using the routing key, but if it is republished then nacked by the recovery strategy, the queue name will be used as the routing key.

[humanamburu]

@cressie176 thank you a lot for your input, it helps a lot to understand better how it works under the hood. We applied the workaround you proposed and bind “queue” as a key.

Thanks again.