Rerunning duplicate_task can cause duplicates

[dmitriim]

Currently duplicate_task grabs a list of modules to be duplicated and then backs them up and restore one by one.

If you have 100 modules to duplicate and process 99, but the last one fails (throw any exception for any reason), then whole task is marked as failed and will be rerun again after 'fail delay' period.

So next time all 99 modules will be restored again and if it fails again, it will restart again and again and so on.

From my point of view there are few way this can be improved:

1. The easiest way is never restart the task if it fails. That will leave us with only some modules being restored. It won't create any duplicates. The extra option for this one can be to not fail whole task if one activity failed. So catch the error, log it and then move on.
2. Track completed and failed modules, then retry only those failed. This will however mess with the order of activities.
3. Clean up after it fails and then rerun the original task. So in this case on fail we will try to delete all just created modules. But it's not guaranteed that the clean up will succeed. As it potentially can also fail.

The down side of any way we pick is lack of feedback for a user so it's not really clear what's happening without looking through logs and etc.

[PhMemmel]

Thank you @dmitriim for reporting this issue. I agree that this is not ideal.

What solution do you personally prefer? Personally, I probably would go for the following (which is your option 1):

• If a course module duplication fails, catch the exception, log it, and continue the job.
• Though it is not very clean, I would let the job finish and mark itself as successful (although technically it was not completely) to avoid a rescheduling of the task.
• User feedback still missing in this scenario, but I do not have an idea on how to deal with that without writing really a lot of code which probably is not worth.

Option 2: I'd rather not choose this, because if one duplication fails it is very likely that this is not a temporary issue, but there are some inconsistencies or sth else, so an admin or developer has to deal with this.
Option 3: See option 2.

[dmitriim]

Hi @PhMemmel

Agree. Option 1 is the best in that case. I'd suggest logging errors using events API so we can provide some sort of feedback via events (could be seen in Moodle logs) or potentially configure tools like tool_trigger to notify a user via email.

[TomoTsuyuki]

I made PR #90 for this issue.
Please review and merge if it's ok.

[TomoTsuyuki]

I made PR for 401 branch

For master #90
For 4.1 #97