## General developer forum

### Task API, a task running but seemingly not calling the cron function

Task API, a task running but seemingly not calling the cron function

Hi all,

I am trying to understand how the Task API works. That page does not seem to explain how things work down to the level of the actual cron function of a plugin getting called.

I'm looking at the inactive user cleanup plugin.I have two sites running, A is cleaning up users as expected, B is not.

I have added echo statements in tool_inactive_user_cleanup_cron() in lib.php of the plugin. When I run cron manually on A, I get all the debug output I have inserted on the site. When I run it on B, all I get is:

Execute scheduled task: Inactive User Cleanup (tool_inactive_user_cleanup\task\tool_inactive_user_cleanup_task)
... started 10:38:17. Current memory use 21.3Mt.
... used 0 dbqueries
... used 0.0062000751495361 seconds

So it seems the actual function is not getting run at all. When I look at the plugin code tool_inactive_user_cleanup_task::execute() is empty. So I don't really know how the function in lib.php is supposed to be called in the first place, but on site A, it obviously IS getting called.

Could someone explain? Thanks.

Average of ratings: -
Re: Task API, a task running but seemingly not calling the cron function
Update: I added an echo statement in tool_inactive_user_cleanup_task::execute()
    public function execute() {
echo "execute()\n";
}//end of function execute()

Now this seems to get output both in A and B:
Execute scheduled task: Inactive User Cleanup (tool_inactive_user_cleanup\task\tool_inactive_user_cleanup_task)
... started 11:56:05. Current memory use 21.3Mt.
execute()
... used 0 dbqueries
... used 0.0056869983673096 seconds

The detail I forgot unmentioned: A is running Moodle 3.2, B is running Moodle 3.0. Should I actually be calling tool_inactive_user_cleanup_cron() explicitly from execute() in Moodle 3.0?

Average of ratings: -
Re: Task API, a task running but seemingly not calling the cron function

Hi Olli,
why not filing an issue in https://github.com/dualcube/moodle-tool_inactive_user_cleanup/issues?

It looks like that plug-in didn't properly implement the Moodle Task API, as you've seen: it still uses the cron legacy (https://moodle.org/mod/forum/discuss.php?d=362684) way to implement a "scheduled task" while it could route the actual implementation to one of them, based on the Moodle version the plug-in is running into.

The "empty" task is executed since they've declared the class name of that task: https://github.com/dualcube/moodle-tool_inactive_user_cleanup/commit/08d4ec3dab06ae649f40a05628953ed2799385ab#diff-994acb29f57f0589db12a0f7e0fd4f88R4 .

The different behavior in 3.0 and 3.2 could be due to core code "cleanup".

HTH,
Matteo

Average of ratings: Useful (1)
Re: Task API, a task running but seemingly not calling the cron function

Thanks Matteo!

What confuses me is that the legacy code seems to work in 3.2 but not in 3.0.

I.e. both of them seem to call execute() just fine, but tool_inactive_user_cleanup_cron() in lib.php only gets called in Moodle 3.2?

I am looking for a solution on how to fix this myself on a short notice. Do you mean I should move the code in tool_inactive_user_cleanup_cron() to execute() ?

I'll be happy to submit a patch to them of course if this gets resolved.

Average of ratings: -
Re: Task API, a task running but seemingly not calling the cron function
The forum just destroyed my edits to my previous post since the edit time ended. Really wish the guideline from nearly 10 years ago were implemented. Or discussed.

To the point, I could not easily find documentation for the old Cron API so I am not sure what in inactive_user_cleanup are the parts that are using the old API and what are using the new API. So I am not quite sure what to write in that issue. I am posting here to just first understand how the APIs work in the first place.

Average of ratings: -
Re: Task API, a task running but seemingly not calling the cron function

Hi Olli,
shortly:

i.e.:

• you should isolate the actual execution logic
• call it within the right place depending on the Moodle version. The plug-in declares to support something in between the development of Moodle 2.4 in $plugin->requires - 2.4 beta, some weeks before the GA - so you can assume that it should work on both legacy and w/ Task API, being the latter available since 2.7 • since you cannot use a singleton here to be sure that the code is executed once - twice hurts none but a good design - you need to create a condition to decide which way of call the execution. I'd use 2.7 i.e. 2014051200 to mark the baseline for the routing: legacy before and scheduled task when$CFG->version >= 2014051200

You could even decide to create a version where legacy cron is no more supported i.e. it could be installed on 2.7+ only.

HTH,
Matteo

Average of ratings: -
Re: Task API, a task running but seemingly not calling the cron function

Thanks Matteo. This clears things up quite a bit. It may be that we will end up just updating the site to (at least) Moodle 3.2 since this seems to work out of the box there, though it seems unclear why.

Average of ratings: -
Re: Task API, a task running but seemingly not calling the cron function

Turns out this is not a Moodle version dependent issue but somehow related to the specific site. It appears even after updating the site from 3.0 to 3.2.

I tried to transition the cleanup code to the new Task API but it seems the environment there is different enough that the database query in there did not work. Will need to figure out if I can debug it further.

Average of ratings: -
Re: Task API, a task running but seemingly not calling the cron function

It turns out there's a setting for 'Legacy cron processing for plugins', which was turned off. So even though inactive_user_cleanup task was turned on, that didn't help as it depended on that other Task being turned on.

Usability recommendation: If there's a such a modality in the system, i.e. dependency on another Task, please make it visible in the system.

I.e. could Moodle detect if a plugin depends on 'Legacy cron processing' being turned on?

-> and then alert the user that they still have to turn that on if they have a dependent Task turned on.

i.e tell them that it's not enough for the task of the plugin itself to be on.

Average of ratings: -
Re: Task API, a task running but seemingly not calling the cron function

Hi Olli,

I don't think your interface suggestion would work because there is no connection between legacy cron and any tasks. In other words, you could have a plugin which contains both a legacy cron function and one or more tasks, and these can do entirely different things. It's not the case that these are somehow two switches for the same functionality.

Really in the case you describe the plugin is clearly broken (because it apparently defines a 'task' that does nothing) so the usability confusion is mainly caused by the plugin, not with the Moodle interface. If the plugin were implemented correctly, it would either:

a) not have any tasks, still relying on legacy cron

or

b) have a task that actually does the work, not needing legacy cron to be turned on

So, somebody should fix the plugin.

It might be possible to make Moodle generate (for administrators) a list of plugins that require legacy cron to be enabled, so you can see if you need to run it. The only problem with this is there's no way for it to tell for certain - it could look for the existence of a legacy cron function, but if the plugin wants to be supported across older Moodle versions, it's possible that it might have both the legacy cron function and the newer tasks, with the cron function doing nothing on newer versions where the tasks are assumed to do the work...

--sam

Average of ratings: Useful (1)