Help needed: 'delay/schedule a task' full example requested

You would simply use your event Insert entity followed by an action Enqueue a task with a delay which could be configured like this:

Then you need another event ECA processing queued task where you configure the same Task name as in the action. Following that event you can then do anything you want, just like with any other event, e.g. you can send the email on that event.

Here is what happens in the background:

When enqueuing a task, ECA puts an item into Drupal's queue. And items in that queue get executed when Drupal's cron is running. When there is a task like this during processing, the event to process enqueued ECA tasks will pick this up. It receives all the entities that the action forwarded and then the actions following that event can deal with that entity just as if they were executed right away, i.e. without the queue and without any delay.

Thanks jurgenhaas for your quick reply (as always).

This is how I supposed it to be set but the email is then sent as soon as cron runs, even when run below delay set for the enqueued task (eg. when manually triggered using drush).
I've tried playing with the 'Distribute' and 'Cron run time' settings of the 'ECA processing queued task' event with no more success, still sent on next cron run.

Attached file is my updated process (shorten process with 1min delay for testing purposes and using MailHog for local mail).
Did a miss a step?

Ah, there is indeed a bug in the configuration submit function:

  public function submitConfigurationForm(array &$form, FormStateInterface $form_state): void {
    $this->configuration['delay_value'] = $form_state->getValue('task_name');
    $this->configuration['delay_unit'] = $form_state->getValue('delay_unit');
    parent::submitConfigurationForm($form, $form_state);
  }

This leads to a delay value of always zero. The second lines needs to be $this->configuration['delay_value'] = $form_state->getValue('task_value'); instead.

Going to provide an MR shortly.

I've tried the patch:

1. Existings ECA processes using queue delay should be resaved after patching so the 'delay_value' can be updated
   
   
2. First cron run triggered by drush before delay outputs the following error in Terminal: [error] Drupal\eca_queue\Exception\NotYetDueForProcessingException: Task is not yet due for processing. in Drupal\eca_queue\Plugin\QueueWorker\TaskWorker->processItem() (line 83 of /Users/.../web/modules/contrib/eca/modules/queue/src/Plugin/QueueWorker/TaskWorker.php).
   => email is not sent (as excepted)
   Well, this seems to be a warning more than an error since as stated: Task is not yet due for processing
   
   
3. Second cron run triggered by drush after delay outputs no error
   => email is sent
   
   
4. First cron run triggered by Drupal admin UI before delay outputs no error
   => email is not sent (as excepted)
   
   
5. Second cron run triggered by Drupal admin UI after delay outputs no error
   => email is sent
   
   

So, it works! thank you

Can the queue be processing more often with a lighter cron than the Drupal cron?
I remember back in Rules time that the Rules Scheduler has it's own cron url to process its own tasks only.

Fix got merged and back ported to 1.1.x and 1.0.x

@PhilY Drupal core's queue comes with a Drush command queue:run which requires the queue name as an argument. The queue name for ECA is called eca_task, so you can call it independently from cron like this:

drush queue:run eca_task

@jurgenhaas: thanks for quick support / fix / help.

😊

Back with extended tests.

This is my first time playing with queue processes so I may be missing a step.
I'm reporting here the observed behavior hoping this can help.
Maybe the "Task is not yet due for processing" error is not that innocent.

When tasks are queued using « Enqueue a task with a delay », they are added to the queue with an expire timestamp set to 0 (checked using the queue_ui contrib module).

First run of drush queue:run eca_task command outputs error « Task is not yet due for processing » in Terminal and in Drupal watchdog log for each pending tasks but their expire timestamps have now been updated in the queue_ui interface.

Second and later runs of drush queue:run eca_task command seem to do nothing more: tasks are not processed even after delay expiration.

Only a Drupal regular cron processes the queued tasks.

This does not occurs when using the « Enqueue a task » task (the one without delay): tasks are queued with an expire timestamp set to 0 as well but are processed on first run of either drush queue:run eca_task or cron, whichever occurs first.

I'll later try some tests on a blank D9 website to check if same behaviour occurs.

This is a fixed issue and continued discussions are not recommended in that stage. Just for the record, a quick feedback on the question you raised:

Drupal's queue is managed such that tasks (either due immediately or delayed) will be sent to a task processor. If that task is due and gets processed successfully, the task is being removed from the queue. If the task is not processed, either because it's not due yet or processing failed and the processor expects a retry, then the task goes back to the queue, but it's being locked. This is necessary to prevent double processing of the same task in parallel. So, there is a mechanism required to unlock such tasks in the queue after a period of time, and that's what cron does.

Automatically closed - issue fixed for 2 weeks with no activity.

Hello,

Thanks for you work on this.

I am trying to test out this patch as we would like to have this working on our project as well.

When I try to patch the 1.1.4 version of ECA with the following code in our composer.json file It says unable to patch.

          "drupal/eca": {
              "https://www.drupal.org/project/eca/issues/3347247": "https://git.drupalcode.org/project/eca/-/merge_requests/319.diff"
          }

Can you tell me if I am missing something small?

Thanks!

This should already be in the 1.1.x branch, see #11