QueueWorker plugin derivatives

The other issue not a duplicate

Hmm, neither patch seems to help in my case, I'm trying to get node_revision_delete cron to get recognized, maybe another issue involved.

Are you using the option to expose single queues as their own job?

Either way, node_revision_delete uses a single, regular queue. Without that option, you won't see anything, but it should just work, it will always call all queues that have any data in them. Check with drush queue:list or manually in the queue table if there's any data to process.

If you do use the option (which I don't recommend), you should see the queue job show up when you rebuild jobs, and then same.

node_revision_delete version 2.0.x does not have a hook_cron, it has an QueueWorker class

/**
 * Delete revisions for a node.
 *
 * @QueueWorker(
 *   id = "node_revision_delete",
 *   title = @Translation("Node revision delete"),
 *   cron = {"time" = 300}
 * )
 */
class NodeRevisionDelete extends QueueWorkerBase implements ContainerFactoryPluginInterface {

with that said, node_revision_delete 1.x has a hook_cron, this works with Ultimate Cron, but not 2.0.x version of nrd

I'm not sure if I understood your suggestion. Maybe you're not aware of the differences between node_revision_delete 1.x and 2.x

This is the first time I've seen a QueueWorker class. I'd have to look this up to understand when it came in and what it's about.

✨ Support for Ultimate Cron Active

You don't need a Job for queues, they run every time cron runs.

ok so is there a way to say, "queue for nrd, run only between 04:00 AM and 05:00 AM"?
how do we set up an Ultimate Cron functionality with a queue?

> This is the first time I've seen a QueueWorker class. I'd have to look this up to understand when it came in and what it's about.

The queue system has existed for a very long time and you *very* likely relied on them before without knowing it. media_entity in core uses queues conditionally, entity_reference_revisions uses queues for for orphan cleanup, drush queue:list probably shows a bunch of them on your project.

A queue will only process stuff if something has explicitly added items to the queue. For node_delete_revisions, that happens when nodes are updated, then they will be checked on the next cron run. This is completely different to how 1.x worked, which had expensive queries that did run on every cron execution. Queues typically also have a fixed time limit per cron run per queue, so they run at most 30s or 60s or something like that.

in my experience, you very rarely need to control when they run. You can do that, with the mentioned setting that will expose each queue as its own job. Then you could set them up to either not run at all and set up separate queue processing with drush queue:run or run them at specific times. But that causes risks

The other thing you can do is alter their definition and lower their execution limit, so that they run only 10s for each cron run or so.

This issue is a about a very specific edge case with queue workers created as derivatives, which causes invalid job names combined with that optional setting.

A queue will only process stuff if something has explicitly added items to the queue. For node_delete_revisions, that happens when nodes are updated, then they will be checked on the next cron run.

So how would this then delete revisions older then x months form a node that has not been touched recently?

I don't know and was wondering about that too, but that is an issue with node_delete_revisions, not this module. I guess at the moment the answer is "not" ;)

Committed this, prefer the changed separator over keeping __ of the other issue.

This does mean that existing jobs will be duplicated, but they weren't working before, so that's fine by me.

This breaks the updated tests which now use such a queue plugin in the edit test. This also means that we should able to test this pretty easily.