>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3626967. --> Reported by: [fgm](https://www.drupal.org/user/27985) >>> <!-- Draft for a new drupal.org issue on the mongodb project, 2026-09-30. Title: Evaluate DelayableQueueInterface support in the MongoDB queue Category: Plan. Version: 8.x-2.x-dev. Component: Code (mongodb_storage). Related issues: #3626957, #3130220. The comparison table comes from reading each project's code on git.drupalcode.org on 2026-09-30, not from running it. The AI disclosure section at the end is a placeholder for FGM to write. --><h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>Core added <code>Drupal\Core\Queue\DelayableQueueInterface</code> in Drupal 9.1.0, with <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/drupal/issues/3116478" title="Status: Closed (fixed)">#3116478: Add a way to silently keep an item locked when processing a queue via cron</a></span>. Its single method, <code>delayItem($item, int $delay)</code>, sets the expiry of the current claim on an item to the current time plus <code>$delay</code> seconds. The item stays claimed until then, and becomes available again after that.</p> <p>Core's <code>DatabaseQueue</code> implements it, and <code>Drupal\Core\Cron</code> uses it: when a queue worker throws <code>DelayedRequeueException</code>, cron calls <code>delayItem()</code> with the delay from the exception if the queue implements the interface. Otherwise, cron leaves the item's current claim alone, so the item becomes available again when its original claim expires. No item is lost; only the delay requested by the worker is ignored.</p> <p>The <code>mongodb_storage</code> queue was written in <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/mongodb/-/work_items/3130220" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/mongodb/-/work_items/3130220</a></span> before the interface existed, and does not implement it.</p> <p>Most contrib queue backends do not implement it either. This comparison covers the default development branch of each project, as found in its code on 2026-09-30:</p> <table> <tr> <th>Project, branch, class</th> <th>Declares Drupal 10/11</th> <th><code>DelayableQueueInterface</code></th> <th><code>releaseItem()</code> on an item that is not claimed</th> </tr> <tr> <td>core <code>DatabaseQueue</code>, <code>Batch</code></td> <td>yes</td> <td>yes</td> <td>TRUE</td> </tr> <tr> <td>core <code>Memory</code>, <code>BatchMemory</code></td> <td>yes</td> <td>no</td> <td>FALSE</td> </tr> <tr> <td>mongodb 8.x-2.x <code>Queue</code></td> <td>yes</td> <td>no</td> <td>FALSE</td> </tr> <tr> <td>mongodb 3.x: core <code>DatabaseQueue</code> on the MongoDB database driver, with a core patch adapting its queries</td> <td>Drupal 11.1 only</td> <td>yes, core's</td> <td>TRUE: the driver's updates return the matched count</td> </tr> <tr> <td>redis 2.x <code>RedisQueue</code>, <code>ReliableRedisQueue</code></td> <td>yes</td> <td>no</td> <td>TRUE</td> </tr> <tr> <td>redis 8.x-1.x, all queue classes</td> <td>yes</td> <td>no</td> <td>no return value (NULL)</td> </tr> <tr> <td>rabbitmq 4.x <code>Queue</code></td> <td>Drupal 10 only</td> <td>no</td> <td>throws an <code>Error</code></td> </tr> <tr> <td>kafka 8.x-1.x <code>KafkaQueue</code></td> <td>yes</td> <td>no</td> <td>TRUE</td> </tr> <tr> <td>queue_unique 8.x-2.x <code>UniqueDatabaseQueue</code></td> <td>no (Drupal 8/9)</td> <td>yes, inherited from <code>DatabaseQueue</code></td> <td>TRUE, inherited</td> </tr> <tr> <td>aws_sqs 8.x-1.x <code>AwsSqsQueue</code></td> <td>no (Drupal 8/9)</td> <td>no</td> <td>depends on the AWS response</td> </tr> <tr> <td>aws_sqs_api 1.0.x <code>AwsSqsQueue</code></td> <td>no (Drupal 9)</td> <td>no</td> <td>no return value (NULL)</td> </tr> <tr> <td>beanstalkd 8.x-1.x <code>BeanstalkdQueue</code></td> <td>no (Drupal 8)</td> <td>no</td> <td>no return value (NULL)</td> </tr> <tr> <td>openstack_queues 8.x-1.x <code>OpenstackQueue</code></td> <td>no (Drupal 8)</td> <td>no</td> <td>FALSE</td> </tr> <tr> <td>advancedqueue 8.x-1.x, own backend API instead of <code>QueueInterface</code></td> <td>yes</td> <td>not applicable: every backend must accept a delay in <code>enqueueJob()</code> and <code>retryJob()</code></td> <td>not applicable: releasing is the optional <code>SupportsReleasingJobsInterface::releaseJob()</code></td> </tr> </table> <p>Advanced Queue is the exception in design rather than in interface: it does not implement <code>QueueInterface</code>, but its own backend API makes delays mandatory, and its processor retries failed jobs after a delay, which is what <code>delayItem()</code> provides for core queues.</p> <p>So among the compared backends not built on core's <code>DatabaseQueue</code>, none implements the interface. The last column shows that behavior also varies where the core interface leaves room, which this plan should keep in mind when deciding how closely to follow core.</p> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <p>Evaluate whether the MongoDB queue should implement <code>DelayableQueueInterface</code>, then either:</p> <ul> <li>create a feature request to implement it, or</li> <li>document in <code>docs/modules/mongodb_storage.md</code> that the queue does not implement it, why, and what happens instead when a worker throws <code>DelayedRequeueException</code>.</li> </ul> <p>Points to evaluate:</p> <ul> <li>Use: which core and contrib queue workers throw <code>DelayedRequeueException</code>, and how often sites would run such workers on a MongoDB queue.</li> <li>Cost: the queue already stores the claim expiry in <code>expires</code>, and <code>claimItem()</code> already treats items with an expired claim as available, so <code>delayItem()</code> would be a single update of <code>expires</code>, like <code>releaseItem()</code>. Tests could follow core's <code>CronQueueTest::testDelayedRequeue()</code>.</li> <li>Compatibility: whether a MongoDB queue meant as a replacement for core's <code>DatabaseQueue</code> should support what it supports, given that other backends do not.</li> <li>Interaction with <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/mongodb/-/work_items/3626957" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/mongodb/-/work_items/3626957</a></span>: whether delaying items affects the ordering guarantees evaluated there.</li> </ul> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <ul> <li>Evaluate the points above.</li> <li>Decide, and record the decision in this issue.</li> <li>Either create the feature request, or update the documentation.</li> </ul> <h3 id="summary-ui-changes">User interface changes</h3> <p>None.</p> <h3 id="summary-api-changes">API changes</h3> <p>None in this plan. A resulting feature request would make <code>Queue</code> also implement <code>DelayableQueueInterface</code>, an addition that does not break callers.</p> <h3 id="summary-data-model-changes">Data model changes</h3> <p>None.</p> <h3 id="summary-ai-disclosure">AI disclosure</h3> <p>Issue created with AI asssitance.</p> > Related issue: [Issue #3116478](https://www.drupal.org/node/3116478)