This is a very specific error, in that it is only triggered in one place in the code, to detect and avoid a particular problem.
The potential problem is that as students interact with a question, it changes state. You can see that when you review a quiz attempt. Under each question is the grey response history area. That has a number of rows in it.
In normal use, what happens is that the student loads one page a quiz with some questions on. They do something, then they submit that page, and the new responses they have given get processed.
The problem comes when they try to do something more complex. For example suppose you
- Open the quiz in the web browser on your computer.
- Open the same quiz on your mobile phone (or in another tab, or another browser, on your computer).
- Answer some questions in the first browser, and click Next or Check or something.
- Go to your mobile, which still contains the questions as they were before the action you too in 3. above, and try to perform a different action here.
Now, Moodle is going to get some data that relates to how the questions were in steps 1. & 2., and which does not account for the changes caused by action 3. That (potentially) makes no sense, and has to be rejected. (Think, in particular, about a question behaviour like Interactive with multiple tries.)
In order to detect this situation, we add a marker to each question in the HTML. For example, if you hunt around in the HTML at https://github.com/moodle/moodle/blob/master/question/engine/questionusage.php#L744, you will find
<input type="hidden" name="q4:1_:sequencecheck" value="3">
This indicates that the first question in this quiz attempt has previously had 3 actions performed on it (which you can see in the response history table). In another action is performed on this question (which could only be manual grading by the teacher since this is a finished quiz attempt) that value will be included with the submitted data, and before anything is processed, Moodle will check in the database, and verify that there are still only 3 actions for this question, before processing the manual grading as a 4th.
Of course, with any mechanism like this that is designed to detect problems, you have to worry about false positives. That is, the mechanism erroneously rejects a submission that is OK. However, this code has been there since Moodle 2.1 and I don't recall anyone else having problems until now.
But, what could be going wrong here? and how might we be able to diagnose it?
It is really hard to think of what might be going wrong. The mechanism is simple and robust.
Places to look for clues:
- Are there any other errors in the PHP error log that might be related?
- Are there any JavaScript errors showing up in the web browser of any student who experiences this?
- Can you look at the the Moodle logs, and the Apache web logs, to try to see what the students who hit this problem were doing immediately before it happened?
- Can you reproduce it yourself?
I am struggling to think of any way that error could be triggered (other than through the kind of weird behaviour that we are intentionally trying to prevent as explained above). I have to vague ideas:
- Could it be that students are double-clicking on the Next button? Now, actually, I already thought of that long ago. You may have notice that when you click on the Next button, all the buttons on the quiz page are immediately disabled, so a second click is ignored. Except that, if your web browser is really slow, and you click really fast, you might be able to beat it. (This is why I suggest looking for JavaScript errors.)
- Could it be that some firewall, or web proxy, or cache, is getting in the way and somehow causing the HTTP request to get duplicated? I don't really believe this one, but if it was happening, you might be able to see it in the Apache logs.
