QueueWorker plugin derivatives

Marking Needs Work, patch failed to apply

This appears to be a duplicate of #3001044: Drupal\Component\Plugin\Exception\PluginNotFoundException: The "feeds_feed_refresh__test_node". Closing this issue in favor of the older issue, which has a similar patch. If this patch is superior in some way, I'd suggest adding it to the other issue.

The other issue not a duplicate

Hmm, neither patch seems to help in my case, I'm trying to get node_revision_delete 2.0.x cron to get recognized, maybe another issue involved.
The 2.0.x version of node_revision_delete does NOT have a hook_cron implementation. Perhaps there's some new way to invoke cron?

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.

#3401632: Support for Ultimate Cron

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

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

> 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.

Added backwards compatibility fallback for legacy __ delimiter format with deprecation notice, post_update migration hook, and kernel tests for derivative discovery/migration.

__derivative_id__ is quite long. config entity ids can be up to 166 characters, see \Drupal\Core\Config\Entity\ConfigEntityStorage::MAX_ID_LENGTH. "ultimate_cron_queue___derivative_id__" is 38 characters, which still leaves 128 characters for the plugin id and derivate id. That's *probably* ok, but would it make sense to add something to handle that?

On the post update, config entities support renames, although there are some edge cases with that still (registering of uuid in key lookups) and our references won't support that, so it probably doesn't make a difference.