3.5.4, 3.6.2, 3.7
MOODLE_35_STABLE, MOODLE_36_STABLE, MOODLE_37_STABLE
- Go into a course (can be new) with at least one student
- Go to Gradebook setup
- Add a new Grade Item, give it an ID Number of g1
- Add a new Grade Item
- Add a category
- Edit the category calculation and set it to =[[g1]]
- Delete grade item 1 (g1)
- Confirm that the page loads.
Separately, use a course with grades and confirm that regrades seem to happen correctly. Like deleting a graded item in the course, and totals updating correctly.Go into a course (can be new) with at least one student Go to Gradebook setup Add a new Grade Item, give it an ID Number of g1 Add a new Grade Item Add a category Edit the category calculation and set it to =[ [g1] ] Delete grade item 1 (g1) Confirm that the page loads. Separately, use a course with grades and confirm that regrades seem to happen correctly. Like deleting a graded item in the course, and totals updating correctly.
We noticed after upgrading to 3.5.4 last night, a number of pages getting permanently stuck on the servers, drawing 100% CPU, and locking user sessions. We traced it to the calendar, which then traced to regrading (the callback to Assign events in the calendar checks grades, which can trigger an entire course regrade...).
From there I narrowed it down to the change made in
Look at the code change here for this to make sense https://github.com/moodle/moodle/commit/e607001e7eb7dddb1216b99bf010eb0d435a2c43
But basically, the change from $count to just checking the count of $finalids to check for a failure does not work.
The problem is that the counter checking for failure needs to be reset each time through the outer while (count($finalids) < count($gids)) loop, but that doesn't happen when we are just using $finalids to check. So in the case I am debugging, the outer loop stabilizes at while (23 < 24), and so never finishes.
This makes me think that the suggested fix in the opening to
MDL-63761 (adding an additional $count++) may be the correct solution here, not the removal of $count.
I'm still working to narrow down the exact scenario that causes the loop to happen.