DataKick manager skip some schedules

[Beeta]

TLDR:
I have many schedules in @datakick manager module that stopped because "next schedule time" is in the past.

Hello,

Today I noticed that products was not imported/updated, and after checking my download and conversion to xml scripts I understand that the problem source was datakick manager's schedules not running. I can see that the issue started on November the 5th at 15:14, some schedules stopped to run the next hour (id 51 52 53 54 in the ).

I don't know why (maybe they failed or there was some server issue) but the module didn't update the next execution time and date so they are now in a limbo waiting for November the 5th 16:14 2023 that is not coming any soon. 🙂

Is it possibile to fix this behaviour?
Maybe checking for this kind of anomalies when cron start and re-arming them?

Pasting the image I now noticed two more schedules affected from this problem (id 56 and 43).

This issue was there even in the past and I always solved manually re-arming the affected schedules again (editing the time in the schedule and then restore the right time) but is starting to getting annoying as some schedules do background work and is difficult to notice if they stop to be scheduled.

Edited November 12, 2023 by Beeta

[nickz]

12 hours ago, Beeta said:

I can see that the issue started on November the 5th at 15:14

Any changes on php version server side?

 

[Beeta]

20 hours ago, nickz said:

Any changes on php version server side?

 

nop

I double checked file permissions too because some time happened that I had run some script as root so datakick (running with webserver users) didn't overwrite those files, but it's now the case.

the odd thing is that I'm not getting errors running them manually

Edited November 13, 2023 by Beeta

[Beeta]

this time I had to recreate schedules as even re-save them didn't make them run again even if next scheduled time column was updated.

[datakick]

This is probably caused by locks.

During processing, every schedule is locked, so it is not picked for execution by different scheduler instances. In theory, the lock should be removed, because there is finally block in the code

lock()
try {
  processSchedule();
} finally {
  unlock();
}

However, is some rare situations, PHP code is non-gracefully terminated, and finally block is never executed. For example, when php server is restarted, or when memory is exhausted. If that happen, the schedule is locked forever.

You can execute this sql to fix it

UPDATE tb_datakick_schedule SET processing = null;

Upcoming version of datakick module comes with a fix for this situation.