LTI Mass Update in 2.18

[Alex-Jordan]

I have 2.18 (ass it currently is) in use in production at my school. It seems that LTI Mass update is not working. Site wide, we have $LTIMassUpdateInterval = 3600; and $LTIGradeMode = 'course';. We are using LTI 1.1 for now.

I see lines like this in the webwork2 log:

[2023-07-05 14:54:45.11744] [239552] [info] LTI Mass Update: Starting grade update for all sets and users.
[2023-07-05 14:54:48.08790] [239552] [info] Updated grades via LTI for course mth095-alex_jordan-202303.

However the grades are not being updated in the LMS (which is D2L). The same is true if I trigger a mass update using the LTIMassUpdate page.

I have enabled $LTIGradeOnSubmit = 1; and now we do see grades being updated slowly, as each active student returns to the course and answers something. So overall the LTI connection is working. There is just something not working about the mass updates.

Is anyone using 2.18 in production with LTI and able to test if mass update is working?

[drgrice1]

Check that the webwork2 job queue is running. Also, if you have updated the code by pulling in changes from GitHub, then make sure that you restart the job queue service.

Other than checking those things, I will need more information to diagnose further.

[Alex-Jordan]

I have done those things already. I'll continue to investigate. I am interested to hear if anyone is using this in production and knows that the mass updates work as expected.

[drgrice1]

I believe that @somiaj is using mass updates with 2.18. I know he reported having an issue at one point, but the issue was that he had pulled a change from GitHub, and forgot to restart the job queue. He said that it worked again after doing that.

[Alex-Jordan]

I think I understand now. In the course I have been studying, I think that the instructor had turned off course grade passback (changing it to none) but changed it back to course recently. Then discovered and reported that things were not updating. So most of the students have no lis_source_did in the database, because that is only recorded when the passback mode is course. Now that it is course, I am seeing a small portionvof the students are getting their grades updated when I trigger a mass update. The webwork2.log has a lot of messages where so and so has a lis_source_did but so and so does not. So I think as students revisit the course, they are finally getting their lis_source_did written to the database and it's catching up.

Do we know if there is a good reason to not simply always record/update the user's lis_source_did, even when grade passback is off or is homework? I am looking at the conditional block starting at line 87 of lib/WeBWorK/Authen/LTIAdvanced/SubmitGrade.pm.

[drgrice1]

The problem is there is no such thing as a user's lis_source_did. A lis_source_did really belongs to a an assignment and user in the LMS not just a user.

If grade passback is homework, then webwork does the natural thing and saves the lis_source_did to the user set table. In this case if we were to also save the lis_source_did to the user table, then we would be changing the lis_source_did in the user table each time the student accesses webwork from a different assignment in the LMS. That really doesn't make sense.

The course grade passback mode is really a hack. We assume there is only one assignment in the LMS and save the lis_source_did to the user table. The assumption with LTI grade passback is that assignments in the LMS are in one-to-one correspondence with assignments in the external LTI tool. The course grade passback mode is not adhering to this assumption.

So the problem is determining where to save the lis_source_did if grade passback is off so that it would be found when it is needed.

[pstaabp]

The troubleshooting of job queue issues is aided with #2232