Urgent Alert: Magento 2 Message Queue Bug Deletes All Locks Hourly, Risking Duplicate Operations

As e-commerce migration experts at Shopping Mover, we are constantly vigilant, monitoring the Magento ecosystem for critical updates and insights that could impact the performance, stability, and data integrity of your online store. Recently, a significant bug report on the Magento 2 GitHub repository (Issue #41599) has surfaced, revealing a long-standing and potentially silent flaw that could be affecting numerous Magento Open Source and Adobe Commerce installations.

The Silent Threat: Magento 2's Message Queue Locks Vanish Hourly

The issue centers around the messagequeue_clean_outdated_locks cron job, a seemingly innocuous but crucial component designed to maintain the health and efficiency of Magento's robust message queue system. This job's intended purpose is to periodically clear out message locks that are genuinely older than a specified interval (defaulting to 24 hours). This mechanism is vital for preventing stale locks from accumulating and clogging the system, while simultaneously ensuring that active messages are protected from being processed multiple times.

However, the bug report highlights a critical miscalculation within this process. Instead of deleting locks older than "now minus 24 hours," the cron job incorrectly computes the cutoff date as "now plus 24 hours." This seemingly minor error has a catastrophic and widespread consequence: every hour, the job effectively deletes ALL existing entries in the queue_lock table, regardless of their actual age.

Why This Matters: The Grave Risk of Duplicate Operations

The queue_lock table plays an absolutely vital role in Magento's message queue framework, particularly for ensuring "at-least-once" delivery with crucial deduplication. Here's how it's supposed to work:

• When a message consumer begins processing a message, it first creates a lock in the queue_lock table.
• If the same message is redelivered by the message broker (e.g., due to a consumer crashing, a timeout, or a network interruption before acknowledgment), the existing lock prevents it from being processed again, throwing a MessageLockException.

With this bug, however, that critical protection is severely compromised. The moment the hourly messagequeue_clean_outdated_locks cron job runs, all locks are wiped clean. If a message is redelivered even a few minutes later, there's no lock to prevent it from being processed a second time. This leads to silent duplicate processing with no error message, making it incredibly difficult to detect without deep investigation.

Consider the potential business impact:

• Order Processing: Duplicate orders, double-charging customers, incorrect inventory deductions.
• Product Updates: Inconsistent product data, incorrect price or stock levels, failed synchronization with ERP/PIM systems.
• Customer Management: Duplicate customer records, redundant email notifications, skewed analytics.
• Inventory Management: Inaccurate stock levels leading to overselling or underselling.
• Integrations: Failed or duplicated data transfers to third-party systems (CRM, shipping, accounting).

This affects critical consumers like async.operations.all (used for asynchronous/bulk REST API operations such as order, product, and customer creation), product_action_attribute.update, various export processes, and inventory consumers. The integrity of your e-commerce data is directly at stake.

Technical Deep Dive: Unpacking the Root Cause

The core of the problem lies within the releaseOutdatedLocks() method in the file app/code/Magento/MessageQueue/Model/ResourceModel/Lock.php. Specifically, the issue is with the use of DateTime::add() instead of DateTime::sub() when calculating the cutoff timestamp:

public function releaseOutdatedLocks()
{
    $date = (new DateTime())->setTimestamp($this->dateTime->gmtTimestamp());
    $date->add(new DateInterval('PT' . $this->interval . 'S'));   // <-- should be sub()
    $this->getConnection()->delete($this->getTable(self::QUEUE_LOCK_TABLE), ['created_at <= ?' => $date]);
}

As demonstrated in the GitHub issue, if the current time is 2026-10-19 12:37:14 UTC and the interval is 86400 seconds (24 hours), the code incorrectly calculates the cutoff as 2026-10-20 12:37:14 UTC. Since all existing locks would have been created before this future date, the SQL query DELETE FROM `queue_lock` WHERE (created_at <= '2026-10-20 12:37:14') ends up deleting every single row in the table.

The issue is further compounded by a unit test (Test/Unit/Model/ResourceModel/LockTest.php::testReleaseOutdatedLocks) that inadvertently pins the wrong behavior, expecting the `add()` operation rather than the correct `sub()`. This explains why this bug has remained undetected since the module was open-sourced, with evidence of the `add()` call dating back to 2017.

Affected Versions and Historical Context

This critical bug has been reproduced on:

• Magento Open Source 2.4.9
• Magento Open Source 2.4.7-p2
• The code remains unchanged in the 2.4-develop branch as of October 2026.

Given its long-standing presence, it's highly probable that many other Magento 2.x versions are also affected, making this a widespread concern for both Open Source and Adobe Commerce users.

Immediate Action and Proposed Solution

The proposed fix is straightforward and targets the root cause directly:

-        $date->add(new DateInterval('PT' . $this->interval . 'S'));
+        $date->sub(new DateInterval('PT' . $this->interval . 'S'));

This change, along with an update to the corresponding unit test, will ensure that only truly outdated locks are removed. While we await an official patch from Magento, affected merchants should consider the following:

• Temporary Patch: Implement a temporary patch by manually applying the code change to your Magento installation. This requires careful testing.
• Monitoring: Closely monitor your message queue consumers and business operations for any signs of duplicate processing.
• Consult Experts: If you suspect your store is affected or require assistance in applying a patch, consult with Magento development experts like Shopping Mover.

Shopping Mover's Perspective: Protecting Your E-commerce Investment

At Shopping Mover, our expertise lies in ensuring the seamless and secure operation of your Magento store, whether you're migrating to a new platform or optimizing your current one. Bugs like Issue #41599 underscore the critical importance of:

• Proactive Monitoring: Regularly reviewing GitHub issues and official Magento updates.
• Code Audits: Conducting thorough code audits, especially for core functionalities and integrations.
• Strategic Patching: Applying critical security and bug fixes promptly and correctly.

For businesses undergoing a Magento migration, understanding and addressing such core platform vulnerabilities is paramount. A healthy source system ensures a smoother transition, and a robust target system guarantees long-term stability. Our team is equipped to help you identify and mitigate such risks, ensuring your e-commerce operations remain efficient and your data pristine.

This bug is a stark reminder that even mature platforms like Magento require continuous vigilance. We urge all Magento 2 store owners and developers to take this issue seriously and prepare to apply the official fix as soon as it becomes available. Your data integrity and operational efficiency depend on it.