Contrib.social

Cart expiration should not use a queue

Open on Drupal.org →
Created on 19 February 2025, 4 months ago
Updated 25 April 2025, about 1 month ago

Describe your bug or feature request.

It looks sensible to use the queue system for it because it's something that is possibly slow. However, it's kind of pointless. This probably doesn't happen once it has caught up, but if you change the configuration or enable it on a site with many stale orders, it could be an issue.

\Drupal\commerce_cart\Cron::getOrderIds() does not have a system to know about which orders already are in a queue. It will always get some 250 orders and create then up to 5 queue items from that. This only works under the assumption that by the time it runs again, the queue has been cleaned. For most sites, that must essentially happen in the same cron run, because that's by default when queues are processed.

If there is a backlog of queue items, then cron hook will again create queue items for those that already in another queue. It's not a big deal because already deleted ones should then fail to load them and those queue items will be dealt with quickly.

It also means that the extra checks in the worker to ensure that the order was not updated in the meantime aren't necessary anymore. This also makes the system more extensible. In our case, we don't use cart, and we altered the query to act solely on the status and not the cart flag, but we had to subclass and override the queue plugin to not do the cart check again.

If a bug, provide steps to reproduce it from a clean install.

📌 Task
Status

Active

Version

3.0

Component

Cart

Created by

🇨🇭Switzerland berdir Switzerland

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024