In test_reset_scheduled_tasks_for_component, If the $thirdtask scheduled task contains random timings (only minute tested) this test will fail. The behaviour of the random timings is not accounted for in this test, so it will fail. This was identified when adding a new scheduled task that contains random minute timing to the 'moodle' component. See MDL-66222 for details on the task.

This results in the error:

1) core_scheduled_task_testcase::test_reset_scheduled_tasks_for_component

Failed asserting that two objects are equal.

--- Expected

+++ Actual@@ @@ 

core\task\antivirus_cleanup_task Object (

     'hour' => '0'

-    'minute' => '17'

+    'minute' => '3'

     'day' => '*'

     'month' => '*'

     'dayofweek' => '*'

/home/travis/build/Peterburnett/moodle/lib/tests/scheduled_task_test.php:214/home/travis/build/Peterburnett/moodle/lib/phpunit/classes/advanced_testcase.php:80

This was not identified in local development due to a weird split behaviour between databases.

test_reset_scheduled_tasks_for_components implicitly relies on the ordering returned from core\task\manager::load_scheduled_tasks_for_component, which in turn implicitly relies on whatever the database returns.

This causes a split behaviour between MySQL and Postgres (and likely other DB engines as well, however not tested), where the ordering is slightly different, and so the bug was not exposed until run on CI. This may or may not be consequential enough to be its own issue. Attached is some screenshots of the seperation in behaviour between Postgres and MySQL, where MySQL contains the antivirus_cleanup_task, which has randomised minutes.