Magento 2 Message Queue Mayhem: When One Missing RabbitMQ Queue Halts All Consumers

The Core Problem: A Single Point of Failure

Under normal circumstances, if a consumer's queue doesn't exist, the system should ideally log the error, skip that particular consumer, and proceed to spawn other consumers with pending messages. However, the reported bug demonstrates a different, more disruptive behavior:

• Scenario: A store has multiple message consumers configured. One of the queues, say async.operations.all, is accidentally deleted from RabbitMQ.
• Action: A mass attribute update is initiated in the admin, publishing messages for a different, later-defined consumer (e.g., product_action_attribute.update).
• Result: When bin/magento cron:run --group=consumers is executed, instead of skipping the missing queue and processing subsequent messages, the cron job fails with a NOT_FOUND - no queue 'async.operations.all' in vhost '/' error. Crucially, no consumers defined after the broken one are started, leading to a backlog of unprocessed messages.

Unpacking the Technical Root Cause

The detailed analysis in the GitHub issue pinpoints the exact technical flaw. Magento's ConsumersRunner::canBeRun() method, when checking for available messages (via CheckIsAvailableMessagesInQueue::execute()), attempts to dequeue from the specified queue. If the queue is missing, Magento\Framework\Amqp\Queue::dequeue() correctly wraps the broker's NOT_FOUND error into a Magento\Framework\MessageQueue\ConnectionLostException.

Here's where the problem lies:

// Simplified representation of the problematic logic
try {
    // ... attempt to dequeue ...
} catch (\LogicException $e) {
    // This catch block is too narrow!
    // ConnectionLostException (which extends \Exception) is not caught here.
}
// If ConnectionLostException is thrown, it escapes and terminates the cron.

The canBeRun() method's try-catch block is designed to only handle \LogicException. Since ConnectionLostException extends \Exception (a broader type), it bypasses this specific catch block, escapes the loop within run(), and prematurely terminates the entire consumers_runner cron job. This prevents any subsequent consumers from being spawned, regardless of whether they have pending messages or valid queues.

Impact and Resolution

This bug, classified as S2 severity (affecting non-critical data/functionality but requiring a workaround), can lead to significant processing delays and operational headaches for Magento stores relying heavily on message queues. It forces merchants and developers to proactively monitor RabbitMQ queues or face unexpected backlogs.

While no specific code patch was provided in the issue comments (as none were given in the source), the "Release note" within the issue indicates that a fix has been implemented. The resolution would involve broadening the exception handling in canBeRun() or its calling context to gracefully catch ConnectionLostException, log the issue for the specific consumer, and allow the cron job to continue iterating through and spawning other healthy consumers.

For Magento users, this highlights the importance of robust queue management and error monitoring, especially in complex Adobe Commerce environments. Ensuring all configured RabbitMQ queues exist and are healthy is crucial to prevent such cascading failures in your asynchronous processing.