Skip to content

Move LMS roster synchronization to the job queue. - #3183

Merged
Alex-Jordan merged 2 commits into
openwebwork:developfrom
drgrice1:lms-roster-sync-in-job-queue
Sep 2, 2026
Merged

Move LMS roster synchronization to the job queue.#3183
Alex-Jordan merged 2 commits into
openwebwork:developfrom
drgrice1:lms-roster-sync-in-job-queue

Conversation

@drgrice1

Copy link
Copy Markdown
Member

The roster synchronization can take quite some time and be somewhat resource intensive if the course in the LMS happens to be large. There is also no way to determine how long it will take before starting the task. So this moves that task to the job queue. When the "Synchronize LMS Roster" form on the Accounts Manager page is submitted, it will quickly respond with "Roster synchronization queued". The job status can then be seen on the Job Manager page. Once completed, the instructor can see the changes on the Accounts Manager page. Note that the job queue info button shows a complete report stating every user that is added, updated, or dropped. There is a summary at the end of the report.

This is built on top of #3181. If desired this could be considered for a hotfix and replace #3181 since I have it done already.

@drgrice1
drgrice1 force-pushed the lms-roster-sync-in-job-queue branch 2 times, most recently from 930f29a to 9aa157b Compare September 1, 2026 19:11
The names and role provisioning services specification states that a
platform does not need to return all users in a single request to the
names and roles URL, and apparently Canvas (and probably others) does
not return all of them at once if there are enough of them (50 seems to
be the limit that Canvas uses in my testing).  If the first request
contains a `rel="next"` URL in its `link` header, that means that there
are more users to be fetched.  So the LMS roster synchronization handler
needs to follow that returned link as many times as it is returned from
the previous request until all users are obtained.

Since the current code just stops after the first request, and for a
large class does not have all users, this results in the remaining users
being dropped from the webwork course.

I tested this with my Canvas instance with 300 users in a course. That
took about 25 seconds for the initial roster import.  So this also
reveals that this really should be a job queue process, and not in the
current request.  Although, that is not done at this point, and is left
for another pull request and the next release. However, if we feel this
is pressing enough, it can be done now as a hotfix.
The roster synchronization can take quite some time and be somewhat
resource intensive if the course in the LMS happens to be large. There
is also no way to determine how long it will take before starting the
task.  So this moves that task to the job queue.  When the "Synchronize
LMS Roster" form on the Accounts Manager page is submitted, it will
quickly respond with "Roster synchronization queued". The job status can
then be seen on the Job Manager page.  Once completed, the instructor
can see the changes on the Accounts Manager page. Note that the job
queue info button shows a complete report stating every user that is
added, updated, or dropped. There is a summary at the end of the report.
@drgrice1
drgrice1 force-pushed the lms-roster-sync-in-job-queue branch from 9aa157b to 70cadb9 Compare September 1, 2026 20:56
@Alex-Jordan
Alex-Jordan merged commit dbab4bb into openwebwork:develop Sep 2, 2026
2 checks passed
@drgrice1
drgrice1 deleted the lms-roster-sync-in-job-queue branch September 2, 2026 10:28
Alex-Jordan added a commit that referenced this pull request Sep 2, 2026
…otfix

Move LMS roster synchronization to the job queue. (Hotfix of #3183)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants