Queue items for deleted entities

Modules often queue work for an entity ("extract metadata for node 123") and process it later on cron. If the entity is deleted first, the item is still in the queue. A well-written worker skips it; a less careful one throws an exception, and the item is retried on every cron run forever. Drupal Cleanup removes queue items whose target entity no longer exists, for any queue a module declares.

Declaring a queue

Add a queues section to your module's MODULE.drupal_cleanup.yml. Each entry becomes its own task, with the ID queue_entity_orphans:MODULE__KEY:

queues:
  mymodule_process:
    label: 'My module processing jobs for deleted content'
    entity_type: node
    data: scalar

What it removes, and what it never touches

• Removed: unclaimed items whose target entity doesn't exist.
• Kept: items a worker has claimed. This is checked again at the moment of deleting, in case a worker claimed one in between.
• Kept: items whose ID can't be read (wrong shape, missing key).
• Kept: everything in queues nobody declared.

Items are read without instantiating any PHP class (unserialize() with allowed_classes: FALSE); object items are read through their public properties.

Only the database queue

Only core's database queue (the queue table) can be inspected. If a queue is routed to another backend such as Redis or SQS, through $settings['queue_service_NAME'], queue_reliable_service_NAME or queue_default, the task reports unsupported backend and leaves it alone.

Running it

drush cleanup:run --task=queue_entity_orphans:mymodule__mymodule_process --dry-run
drush cleanup:run --task=queue_entity_orphans:mymodule__mymodule_process

Queue cleanup runs in the cron sweep and from Drush, not at the moment content is deleted: scanning a whole queue on every delete would be too slow. Removed items are backed up first and can be restored with drush cleanup:restore {backup-id}.