Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-79966

Tasks: Scheduled task timing (crontab fields) is wrong

XMLWordPrintable

    • MOODLE_403_STABLE
    • MOODLE_401_STABLE, MOODLE_402_STABLE, MOODLE_403_STABLE
    • MDL-79966-m401
    • MDL-79966-m403
    • MDL-79966-main
    • Hide

      This change is thoroughly covered by unit tests but it's definitely possible I might have missed something. You can test manually as follows:

      1. To avoid confusion it is simplest to set your login (e.g. admin user) time zone to the same as the server time zone if it isn't already. You can do this from the user menu / Profile, then Edit profile, then scroll down to Timezone field. The last option on that dropdown is 'Server timezone', choose that and hit save. (When considering tests to run it will also be useful to know what time it currently is in the server time zone.)
      2. Go to Site administration / Server / Tasks / Scheduled tasks.
      3. From the list of tasks, choose any task that won't do any harm if you run it accidentally, for example \block_recent_activity\task\cleanup
      4. Edit the task settings, set some values (see below) for minute/hour/day/month/day of week and hit save (don't tick the 'disabled' or 'reset' checkboxes)
      5. Look at the 'Next run' column and check it has an expected value.

      Repeat the last two steps for each example.

      Here are some examples that behave incorrectly before this change and should now work:

      • Set 'day' to any date number that isn't today (e.g. if it is currently the 12th, you could use 14, or you could use 6 in which case it should do next month), and all other fields *.
        • Expected: The next run should be 00:00 (in server time zone) on the 14th or whatever.
        • Before the fix: It would show a next run at approximately the curernt time on that date, instead of 00:00.
      • Set 'minutes' to 30 and 'hours' to *, and set date to any non-current date number as above.
        • Expected: The next run should be 00:30 on the selected date.
        • Before fix: It used to show a next run at approximately the next hour after current hour on that date, e.g. if you are doing this at 16:10 it would show the next run at 16:30.

      These are specific things that broke in the old system, however since I have rewritten it, it might also be a good idea to test various other options and make sure they work as expected. The rules for this are supposed to roughly match Unix 'crontab', as defined e.g. here https://linux.die.net/man/5/crontab - I believe we now implement all of it except that you can't use the names for days ('Mon' has to be 1) or months ('Jun' has to be 6).

      Show
      This change is thoroughly covered by unit tests but it's definitely possible I might have missed something. You can test manually as follows: To avoid confusion it is simplest to set your login (e.g. admin user) time zone to the same as the server time zone if it isn't already. You can do this from the user menu / Profile, then Edit profile, then scroll down to Timezone field. The last option on that dropdown is 'Server timezone', choose that and hit save. (When considering tests to run it will also be useful to know what time it currently is in the server time zone.) Go to Site administration / Server / Tasks / Scheduled tasks. From the list of tasks, choose any task that won't do any harm if you run it accidentally, for example \block_recent_activity\task\cleanup Edit the task settings, set some values (see below) for minute/hour/day/month/day of week and hit save (don't tick the 'disabled' or 'reset' checkboxes) Look at the 'Next run' column and check it has an expected value. Repeat the last two steps for each example. Here are some examples that behave incorrectly before this change and should now work: Set 'day' to any date number that isn't today (e.g. if it is currently the 12th, you could use 14, or you could use 6 in which case it should do next month), and all other fields *. Expected: The next run should be 00:00 (in server time zone) on the 14th or whatever. Before the fix: It would show a next run at approximately the curernt time on that date, instead of 00:00. Set 'minutes' to 30 and 'hours' to *, and set date to any non-current date number as above. Expected: The next run should be 00:30 on the selected date. Before fix: It used to show a next run at approximately the next hour after current hour on that date, e.g. if you are doing this at 16:10 it would show the next run at 16:30. These are specific things that broke in the old system, however since I have rewritten it, it might also be a good idea to test various other options and make sure they work as expected. The rules for this are supposed to roughly match Unix 'crontab', as defined e.g. here https://linux.die.net/man/5/crontab - I believe we now implement all of it except that you can't use the names for days ('Mon' has to be 1) or months ('Jun' has to be 6).

      The scheduled task timing is incorrect in some cases, and there is insufficient unit testing.

      For example, if the current time is 11:56 and you specify hours for a task as */6 with minutes being *, then the next task run should be 12:00 (and after that 12:01, 12:02, etc). But it will actually calculate 12:57. (This mainly affects tasks which take a significant number of minutes to run.)

      A similar problem happens if you specify hours as * (even if you specify minutes). For example, if you set a test to run at minutes 30 and hours *, but only on Mondays-Fridays. Suppose the current time when this task is scheduled is let's say 15:13, but it's a Saturday. Instead of running first at 00:30 on Monday, the first run will actually be 15:30 on Monday.

      Iit is also possible that it will run tasks on the wrong day. If you set a task to run on Sundays, but only in certain months (e.g. December), then it's possible that the first run will actually be in the correct month but on the wrong day of the week. In my test example, it is scheduled for a Tuesday.

      There may be other problems because the way it calculates is, to use a technical term, totally sketch. I'm going to rewrite and add a ton of test cases.

            quen Sam Marshall
            quen Sam Marshall
            Tim Hunt Tim Hunt
            Andrew Lyons Andrew Lyons
            CiBoT CiBoT
            Votes:
            1 Vote for this issue
            Watchers:
            14 Start watching this issue

              Created:
              Updated:
              Resolved:

                Estimated:
                Original Estimate - 0 minutes
                0m
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 4 hours, 51 minutes
                4h 51m

                  Error rendering 'clockify-timesheets-time-tracking-reports:timer-sidebar'. Please contact your Jira administrators.