An immense thank you to @paulinpaloalto for this.
It is a frequent occurrence that students find that their code runs correctly when they execute it in their online notebook, even to the extent that all the test cases produce the expected results, but that the grader doesn’t accept the solution as correct.
This thread represents the current state of knowledge about causes for this scenario and ways to debug the issues.
1. Fresh copy of your assignment
If you believe your solution is correct, and the autograder is not necessarily marking any function as incorrect, but throwing some kind of an error, it could be because something in the notebook accidentally altered which shouldn’t have been. Save your existing work on your local machine. Here’s how you can download your notebook. Then using the “Help” icon on the top right, fetch a new, fresh copy of the notebook. Fill it using your previous solutions and then try submitting again.
Alternatively, instructions on how to download a fresh copy of your notebook are placed in Week 1 of every DLS course (except Course 1, they are in Week 2). The provided hyperlink is from Course 1.
2. Functions must be self-contained
The grader runs your functions in a different environment than your notebook. If you make any references in your functions to global variables that have been created by earlier cells in your notebook, those globals will not be available when your function is run by the grader. You should only reference arguments passed to the function and local variables defined within the function’s scope. Note that it is ok to call other functions in your notebook, as long as they are “graded” functions.
3. Do not hardcode the size or dimensions of any object
The code we are writing should be general in the sense that it does not make any fixed assumptions about the sizes or dimensions of any of the input objects. For example, do not assume that the number of features is always 12288.
4. Be careful not to break the template code
Most of the code in the notebooks has been provided to us in the form of templates. For the graded parts of the exercise, you literally should not have to touch anything other than the code in the sections demarcated by the lines:
START CODE HERE
…
END CODE HERE
In particular, note that the header comment " # GRADED FUNCTION: function-name " and where applicable, “# UNQ_Cx (UNIQUE CELL IDENTIFIER, DO NOT EDIT)” are required by the grader. Removing or modifying these lines will cause the grader to fail for that function. Deleting one or both of these lines will cause 0 points on that function and any that depend on it. Inserting anything (even a blank line) before that line will also fail. Changing the function name on the comment or inserting any non-white-space characters later on that line will cause the error " Malformed Feedback ".
It is not illegal to add more debugging code, including print statements, but you need to be careful. If you find that you’ve broken something in the template code and want to restore it to its original state, follow the instructions given at the end of the first point above. The simpler idea is to always to click “File → Make a copy” whenever you open the notebook for a given exercise for the first time. That will save you a clean copy of the original state in case you want to refer to it later.
5. Check that your notebook “kernel” is healthy
The notebook “kernels” appear to stop working after sometime of the notebook being open, regardless of whether the notebook is being actively used or not. The symptoms are that nothing happens when you try to run a cell and hitting “Save” causes an error message such as " Connection Lost " or just " error " in a yellow box in the toolbar area. Any time you hit “Save”, it should print a confirmation in the toolbar area and the “Last checkpoint time” in the title line should get updated. If that does not happen, then your kernel is not healthy and needs to be restarted. Do not continue working in that case, since your unsaved changes will be lost unless you take remedial action. Try “Kernel → Restart”. If that doesn’t work, refresh your page. And if that doesn’t help, try reopening your assignment.
6. The grader won’t grade a copy of any of the notebooks
You can use the “File → Make a copy” command in a notebook to make as many copies as you want. Even if the copy contains a “Submit Assignment” button, it is very important to be aware of how the grader works: if you click “Submit Assignment” in any copy of the given assignment notebook, it actually grades only the notebook that is the target of the “Open Notebook” link for that assignment. If you want to get the code in a copy of the notebook graded, you need to rename it to be the “standard” name of the current version of the notebook for that assignment.
7. Error: IndexError(‘list index out of range’)
The autograder throws this specific error when in the notebook you had the option to look at something, particularly a dataset or related, by changing the array index. If you see this error, it means that you need to revert the index value to its original. In case you don’t remember that value or where you changed that value, one solution would be to save your existing work, fetch a new copy of the notebook, fill the new copy with your solutions and submit that.