changing queueOptions will crash next restart
See original GitHub issueLet’s say you have a subscriber like this
@RabbitSubscribe({
exchange: 'dummy',
queue: 'my_queue'
})
You push the app to prod, everything is fine (exchange created if it does not exist, queue created if it does not exist, binding betwen queue and excahnge)
now, you change an option like deadLetterExchange
@RabbitSubscribe({
exchange: 'dummy',
queue: 'my_queue',
queueOptions: {
deadLetterExchange: 'dead-letter-retry'
}
})
The app will not start :
Operation failed: QueueDeclare; 406 (PRECONDITION-FAILED) with message "PRECONDITION_FAILED - inequivalent arg 'x-dead-letter-exchange' for queue 'my_queue' in vhost '/': received the value 'dead-letter-retry' of type 'longstr' but current is none"
I know this is the expected behavior from RabbitMq perspective (i.e multiple consumers may be bound to the queue so it is a bit unsafe to delete+recreate the queue automatically during assertQueue)
However, do you think this is the expected behavior with @RabbitSubscribe ?
I mean, if I explicitly specify the queue, it’s because I want the same queue for all running replicas … (besides, options do not really influence the running behavior of the queue from consumer point of view)
Will you accept a PR where we catch the failure of assertQueue to call deleteQueue + assertQueue ?
In any case, what do you suggest as a workaround to detect the situation automatically and to automatically delete the related queues before this lib calls assertQueue ?
Issue Analytics
- State:
- Created 2 years ago
- Comments:5 (1 by maintainers)

Top Related StackOverflow Question
@underfisk I am the author of the PR so yes it address my concerns 😃
I dont have much time to upgrade the libs in our apps right now, but next app will definitively use the new
assertQueueErrorHandleroptionI’ll close this issue, feel free to reopen for any concerns you may have
Hi @christopheblin, I still get an error even though I’ve replaced the error handler with
forceDeleteAssertQueueErrorHandler. I think the handler is running but the error still occurs.