search

emmarichardson / local_autogroup

A local plugin for Moodle 2.7 onwards which handles the dynamic creation, population and cleanup of groups on courses.
6 stars 19 forks source link

Possible bug or odd behavior #33

Open SYoung3000 opened 2 years ago

SYoung3000 commented 2 years ago

We've seen a strange incidence where a user would not update normally when we made changes to their profile, until it randomly worked, seemingly when making changes to another user. We're a little lost as to where to look as a cause of this.

We have autogroups assigning users to groups based on a customfield - into a large number of groups

(this is a large number of courses, and large number of users with lots of variation in the custom field, potentially 100+ groups per course. All in, it's tens of thousands of groups. We're aware this probably makes us an outlier in the usage of the plugin)

We have assigned a large number of users to a number of groups.

We're aware there has been an issue where the server hit php_max_children and we think that the group process may not have completed in every case in the past. I don't have the logs to prove this, but it might be key to what happened.

With generic information, what happened was this:

We observed that a new user (user1) was not included in all of their of the groups we would expect them to be in (custom_field: test1) - going by course ID, the user had been enrolled in some, but not all, lets say course ID 1-80, but not 80-100 - (this fits with our theory of php_max_children being reached causing the process to fail.)

we needed to get autogroups to enrol the user, as there are a large number of groups to set it's not feasibly really to do it by hand.

We tried checking the listen to groups options to see if this would trigger the user to be added to their group. No results.

We tried changing the value for custom_field to a placeholder. We observed autogroups making calls in the DB. The placeholder group WAS added to all their groups in all their courses, we thought we had a solution

We set the custom_field back to test1 - strangely enough, this didn't update on the courses where it failed to update previously. We were now confused.

After allowing a fair amount of time, we tried updating the values of a random user2 to do some testing, which worked as expected. At this point, about a day later, we spotted that User1 had now had their groups updated. It looks like changing user2 caused user1 to update, but we're absolutely baffled as to why.

We're hoping you can shed some insight on this. Can you advise if there are measures in place to check groups in the event of a failed update? Could the failed update have left some data in place that would cause it to not be updated again? Why would updating another user cause this to update when it didn't happen when we amended the user directly?

emmarichardson commented 2 years ago

Sorry, very slow to respond but only just saw this. Are you still having issues - I have not seen that behavior - could be a caching issue maybe..do you have the bottom two settings checked (groups and group membership)

SYoung3000 commented 2 years ago

Hi Emma, just to update on that, it's inconsistent for us, we do not use the caching options in general, as it slows things down too much, we already find autogroup updates take several hours of solid DB access to complete. however groups don't get edited manually on the site, so hopefully we shouldn't expect issues from that.

We've seen a variety of issues where it just doesn't apply groups to a user when that a user meets the criteria to be added. removing and reapplying the relevant profile element sometimes fixes that, it seems a bit inconsistent.

emmarichardson commented 2 years ago

I tend to think you must have something else going on as I do not see this behavior. Possibly you have another plugin installed that is maybe clashing with auto group?