Since their input creates this message, it doesn't get written to the database, so I don't know what mistake they might have made.
Attempts to get more information out of them have not been fruitful. I just get "oh, well it somehow resolved itself".
Thanks Danny.
I'm also hearing complaints from students about answers being "eaten" by WeBWorK on a similar matrix problem.
Checking that student's page showed something I've never encountered before: no attempts were recorded, but I had to request a new version to be able to check answers. So somehow they were able to submit answers (and have the submission counted by the rereandomization counter) without anything being written to the database.
Could be unrelated. Maybe it's time to start a fresh WeBWorK server with a clean DB.
It seems to me (just noticed a few days ago) that if there are two questions using ProblemRandomize in a gateway quiz then grading causes the grader use the updated numbers for the correct answer making the submission incorrect. Or maybe one answer is not recorded and the other one is marked incorrect.
Are the problems that you reference that include problemRandomize.pl part of the OPL? If so, they should be reported as bugs. The OPL editorial board made the decision not to include problems that include re-randomization hard-coded into the problem itself, so if some of these snuck through then that code should be removed.
As Danny said, the problemRandomize.pl macro causes problems in gateway quizzes. It causes problems even without using the grader. I have also seen problems with it in homework problems. That macro needs to be removed.
In my case, I use periodic re-randomization. (And I never use quizzes; only homework.) Although I've considered turning it off: an unrelated bug that I've reported before (but nobody else can reproduce, so maybe I have something wrong deep in my settings or database...) results in question settings being locked in the database the moment a student even looks at a question. So if I edit a question, or change a weight, the changes only apply to students who haven't started their homework yet.
It used to be the case that settings only got locked after they triggered the re-randomization. Turning the feature off resolves the issue.
Sean, are you using WeBWorK 2.16? That should be fixed for WeBWorK 2.16.
Earlier, I was on "2.16" but it was a preliminary release from last spring. Since then, the official release came, and then there have been some hotfixes. A few weeks ago I pulled and there were actually over 50 commits I hadn't caught up with. I know at one point, you were in a similar place with the pre-release. Have you checked to see if you could benefit from pulling "main"? (And even if you can, it may not have anything to do with the issue of this thread.)
Actually, I was thinking of a related issue that I fixed on this that was regarding opening a problem in the problem editor when problem randomization is turned on. This particular issue is not fixed. Although, this particular issue isn't exactly caused by the same thing. In the case that a student submits an answer to a problem the same thing will happen even if problem randomization is disabled. Problem randomization just makes the issue occur when the student opens the problem instead of after the first submission because at that time the problem count needs to be initialized in the database at that time.
To answer Alex: I've been pulling from main since the beginning of the semester, and everything is up to date.
As far as this randomization bug, I get the occasional frustrated instructor, but I've been trying to warn them all to just be very sure you have everything how you want it before releasing it to students.