-
Bug
-
Resolution: Fixed
-
Critical
-
3.11.9, 4.0.3, 4.1.6, 4.2.3, 4.3
-
MOODLE_311_STABLE, MOODLE_400_STABLE, MOODLE_401_STABLE, MOODLE_402_STABLE, MOODLE_403_STABLE
-
MOODLE_402_STABLE, MOODLE_403_STABLE
-
MDL-75579-403 -
-
6
-
Team Hedgehog 2023 Review 3, Team Hedgehog 2023 Sprint 4.1, Team Hedgehog 2023 Sprint 4.2, Team Hedgehog 2023 Sprint 4.3, Team Hedgehog 2023 Review 4
Steps to replicate
- Login as admin.
- Navigate to Site administration.
- Enable enableasyncbackup setting (Checked).
- Create a course called "Test restore course".
- Navigate to the created course.
- Create some activities (Assign, Quiz...).
- Back up that course.
- Run php admin/cli/adhoc_task.php --execute to complete the backup process.
- Download that backup.
- Apply the attached patch.
- Upload and restore the downloaded backup.
- Make sure to select Delete the contents of this course and then restore option.
- Run php admin/cli/adhoc_task.php --execute to complete the restore process.
- Verify that all the course content is deleted.
- Add a new Assign activity to the course.
- Run php admin/cli/adhoc_task.php --execute again.
- Verify that the new Assign will be deleted.
-
-
-
- Original description by Eric ---*
-
-
We have a site where a teacher setup a course restore with the 'delete course contents' setting enabled. It failed after the delete course content step, but before anything is meaningfully restored to the course. When it failed, the teacher went on to put their content in the course another way.
But because adhoc tasks are always re-tried if they fail, guess what? Once a day, it fires off the restore event, wiping the course content, including any student work from that day...
I would argue that something like restore should never retry - it tries, and if it fails, then it fails, and that's that. There is too much risk that you end up with a perpetually increasing amount of things in the course (if it partially completes) or something like this.
While of course we could just wrap the entire restore task in a try-catch(Throwable), so it never fails, I think that isn't a good solution, because then to logging, it appears successful.
I think we should add a method the adhoc_task abstract called something like allow_retry(): bool that is checked by the cron adhock runner if a adhock task threw an exception. That will allow tasks be reported as a failure, and to implement their own logic on if they should be resubmitted (including some that might just always return false, or some that might use fail delay, or something else to determine that they have failed a number of times, and to stop retrying).
- has been marked as being related by
-
MDL-80267 Asynchronous restore keeps deleting course/student content - Using no-retry flag
- Closed
- Testing discovered
-
MDL-80415 Asynchronous restore should create a backup before performing the restore
- Open
- will be (partly) resolved by
-
IDEA-211 Task API Improvements
- Closed
- will help resolve
-
MDL-68365 Universal solution for Moodle cron error: The course module ... could not be deleted.
- Development in progress