-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
134 invalid task hardening #142
Conversation
7024e4c
to
6d31f41
Compare
60854a4
to
ff89f4a
Compare
ff89f4a
to
3ffa13c
Compare
croncheck.php
Outdated
$delay .= "ADHOC TASK: " .get_class($task) . " Delay: $faildelay\n"; | ||
// Instead of using task API here, we read directly from the database. | ||
// This stops errors originating from broken tasks, and allows the DB to de-duplicate them. | ||
$adhoctasks = $DB->get_records_sql(" SELECT classname, COUNT(*) count, MAX(faildelay) faildelay |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this all looks great, the only nit pick is adding line breaks to the sql after each comma
possibly you should also sort the tasks by cumulative faildelay
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this all looks great, the only nit pick is adding line breaks to the sql after each comma
Do you mean:
SELECT classname,
COUNT(*) count,
MAX(faildelay) faildelay
...
(if this is what you mean) IMO I prefer the select parameters all on the one line, with the SQL 'verb' always being at the start
possibly you should also sort the tasks by cumulative faildelay
I have added this:
WARNING: Moodle task faildelay > 60 mins
ADHOC TASK: \tool_dataprivacy\task\process_data_request_task Delay: 1000 (13 duplicates!!!)
ADHOC TASK: \tool_dataprivacy\task\initiate_data_request_task Delay: 6001
(Checked Oct 9 16:20:48)
Closes #134
Closes #136
Changes
Removed use of task
\core\task\manager
.It's much more reliable to just read the data directly from the database. This is because the manager class can throw errors, or the task class itself can throw them like described in the #134. The manager class also outputs debugging if the task is not found, which pollutes the output (unless we force disable debugging).
Its much simpler and cleaner to just read directly from the DB. We lose the ability to get the scheduled task name, but IMO this is not a big deal since you can just read it from the class.
Using the DB also has the advantage of being able to easily de-dup the tasks (For #136)
Added try/catch for check API errors
If a check class is broken or throws an exception, now we get a nice error message:
This indicates something went really wrong, since ideally check classes should always be properly linked.
I'm still a little undecided whether to include just the message, or the full error (incl. stacktrace). I leaned towards full error so that you can tell what plugin/code is throwing the error.
Testing / example: