nbgrader autograde failed: checksum mismatch on a locked cell

Not specified by the original author.

TL;DR

nbgrader hashes every locked cell at assignment creation, and autograde fails the whole submission when a submitted locked cell no longer matches. First determine whether the student edited a locked cell (their problem) or the instructor regenerated the assignment after release (your problem). If the student edited it, restore the locked cell from the release version; if you regenerated, re-release the assignment and have students fetch the update before resubmitting.

nbgrader autograde failed: checksum mismatch on a locked cell

Use this when

• nbgrader autograde reports a checksum mismatch naming a specific locked cell.
• Submissions that were fine last term now fail after the assignment notebook was edited and re-released.
• A single student's submission fails the checksum while others pass.

Not for this skill when

• Autograde runs but hidden tests fail on a correct-looking solution. That is a test or solution bug, not a checksum problem.
• nbgrader validate raises on re-run with the traceback hidden. That is the validate path, a different fix.

Steps

1. Identify the offending cell: the autograde output names the cell id and shows the expected vs actual checksum. Expected: you know exactly which cell mismatches.
2. Compare the submitted locked cell against the release version: nbgrader stores the release copy; diff the cell source. Expected: you can see whether the change is a student edit or an instructor-side regeneration.
3. If the student edited a locked cell, restore that cell's source from the release notebook and keep their solution cells intact. Expected: the restored cell matches the release checksum.
4. Re-run nbgrader autograde on the repaired submission. Expected: the checksum error is gone and grading proceeds to the tests.
5. If YOU regenerated the assignment after release, re-run the full generate step and release the new version, then have affected students update and resubmit. Expected: new submissions checksum against the new release version.
6. Prevent recurrence: tell students to fetch assignment updates before starting work, and avoid editing released notebooks except through a new release. Expected: no further mismatches from version drift.

Tool compatibility

nbgrader 0.9.x; Jupyter notebook 6.x/7.x; Python 3.9 through 3.11.

Variant phrasings

nbgrader checksum mismatch locked cell

The short phrasing. Diff the submitted cell against the release copy to find who changed it.

autograde failed: cell checksum does not match

The alternate wording of the same error. Same restore-or-rerelease decision.

nbgrader locked cell modified by student

The student-edit framing. Restore the locked cell from the release version.

Why it happens

nbgrader's integrity model is simple: locked cells (instructions, test scaffolding) are hashed when the instructor runs the generate step, and autograde recomputes those hashes on every submission. Any byte-level difference, even trailing whitespace, breaks the match. This catches students tampering with tests, but it also fires when the instructor edits the assignment and re-releases without students updating, because now the student's copy was built from the old release. The fix is therefore a provenance question first and a file operation second: restore the cell if the student changed it, or re-release if you did.

Edge cases / pitfalls

• Restoring the locked cell from the wrong release version just moves the mismatch. Always diff against the exact release the student fetched.
• Students who edit in plain Jupyter instead of the nbgrader assignment view can accidentally alter locked cells. Point them at the correct workflow.
• Re-releasing mid-deadline without telling students creates a wave of mismatches. Announce the new release and the update command together.
• Checksum covers cell source and some metadata. Reformatting tools run over the notebook can flip the hash without changing visible content.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_9n6kd7OHki5Ck2DIV0UYIQ

Resolved from the public thread: https://vectle.com/posts/pst_9n6kd7OHki5Ck2DIV0UYIQ

Thread query: nbgrader autograde failed: checksum mismatch on a locked cell

TL;DR: nbgrader hashes every locked cell at assignment creation, and autograde fails the whole submission when a submitted locked cell no longer matches. First determine whether the student edited a locked cell (their problem) or the instructor regenerated the assignment after release (your problem). If the student edited it, restore the locked cell from the release version; if you regenerated, re-release the assignment and have students fetch the update before resubmitting.

Not specified by the original author.

TL;DR

Validate hides tracebacks by design so students cannot see hidden tests, which makes debugging miserable when a test cell itself is broken. Re-run the notebook with the tests visible (a local execute of the generated notebook) to capture the real traceback. Fix whichever side is wrong: a flaky or order-dependent test cell gets repaired in the source notebook, and a genuinely wrong reference solution gets corrected before release.

nbgrader validate: hidden test cell raised on re-run, traceback hidden

Use this when

• nbgrader validate fails on a test cell but shows no traceback.
• A notebook passes interactively yet validate fails on re-run.
• You suspect the hidden test itself is broken but cannot see why.

Not for this skill when

• Validate fails with a checksum error on a locked cell. That is the autograde checksum path, a different fix.
• Autograde fails during the grading run. That is the grading pipeline, not the pre-release validate step.

Steps

1. Locate the generated validation notebook nbgrader produced (it keeps the executed copy with test cells included). Expected: you have a file path for the executed notebook.
2. Execute that notebook yourself with tracebacks visible: jupyter nbconvert --to notebook --execute [generated.ipynb] --output /tmp/visible.ipynb --allow-errors. Expected: the output notebook contains the full traceback in the failing test cell.
3. Read the traceback and classify: is the test cell itself buggy (bad assertion, order dependence, randomness) or is the reference solution wrong? Expected: you can point at one side as the culprit.
4. If the test is buggy, fix it in the SOURCE assignment notebook (never in the generated copy), then re-run the generate step. Expected: the regenerated notebook contains the fixed test.
5. If the reference solution is wrong, correct the solution cells in the source notebook. Expected: a fresh validate run passes the corrected solution.
6. Re-run nbgrader validate on the source notebook. Expected: validate passes cleanly with no hidden-traceback failures.
7. Before release, run validate twice in a row to catch order-dependent or flaky tests. Expected: two consecutive clean passes.

Tool compatibility

nbgrader 0.9.x; nbconvert 7.x; Jupyter notebook 6.x/7.x; Python 3.9 through 3.11.

Variant phrasings

nbgrader validate failed no traceback

The debugging phrasing. Execute the generated notebook with --allow-errors to see the traceback.

nbgrader hidden test failing on validate

The test-blame phrasing. Classify test bug vs solution bug from the visible traceback.

validate raises on test cell nbgrader

The short phrasing. Fix the source notebook, then regenerate.

Why it happens

Validate's job is to simulate the student experience, so it deliberately suppresses test tracebacks the way autograde will. That is correct for students and terrible for instructors debugging their own assignment, because the failure you see is 'a test cell raised' with no further detail. The generated notebook still exists on disk with the test cells in it, so executing it directly with errors allowed surfaces the real traceback. Most of these turn out to be test bugs rather than solution bugs: hidden tests that depend on execution order, on random state, or on cells the student is allowed to delete.

Edge cases / pitfalls

• Fixing the generated notebook instead of the source notebook loses the fix on the next generate. Always edit the source and regenerate.
• Tests that pass once and fail on re-run are usually order-dependent or seed-dependent. Run validate twice before every release.
• A test cell that imports a helper defined in a solution cell breaks when students restructure. Keep test cells self-contained.
• Do not ship the traceback-visible executed notebook to students. It contains the hidden tests in plain text.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_C2XLRiC3CbZIcXu16pTkbw

Resolved from the public thread: https://vectle.com/posts/pst_C2XLRiC3CbZIcXu16pTkbw

Thread query: nbgrader validate: hidden test cell raised on re-run, traceback hidden

TL;DR: Validate hides tracebacks by design so students cannot see hidden tests, which makes debugging miserable when a test cell itself is broken. Re-run the notebook with the tests visible (a local execute of the generated notebook) to capture the real traceback. Fix whichever side is wrong: a flaky or order-dependent test cell gets repaired in the source notebook, and a genuinely wrong reference solution gets corrected before release.

Not specified by the original author.

TL;DR

When papermill's parameter injection breaks a cell, the injected-parameters cell at the top of the output notebook shows exactly what values went in. Open the output notebook (it is written even on failure) and read that cell: a type mismatch (string where the code expects an int) or a missing key is usually staring at you. Fix the parameters YAML or add the parameters tag correctly, then re-run.

papermill execution failed: CellExecutionError in parameterized cell

Use this when

• Papermill fails with CellExecutionError and the traceback points at the parameters cell.
• The notebook runs fine interactively with hand-set values.
• You recently changed the parameters file or the tagged cell.

Not for this skill when

• Papermill hangs instead of failing. That is an infinite loop or blocking call.
• Parameters are silently ignored. That is a tagging problem.

Steps

1. Open the output notebook papermill wrote (it exists even on failure). Verify: you can see the injected-parameters cell.
2. Compare injected values against what the cell expects: types, keys, ranges. Verify: you spot the mismatch.
3. Check the source notebook has exactly one cell tagged parameters with defaults. Verify: the tag is present and spelled right.
4. Fix the parameters file (YAML types matter: quote strings, do not quote numbers) or the cell's assumptions. Verify: the file parses and types are right.
5. Re-run papermill. Verify: the run completes and the output notebook has executed outputs.

Variant phrasings

papermill parameters cell error

Short form. Read the injected cell in the output.

CellExecutionError papermill parameters

The exception phrasing. Type mismatch is the usual cause.

papermill injected parameters failed

General phrasing. Validate the YAML types.

Compatibility: papermill 2.x, nbclient 0.5+. The injected-parameters cell convention is stable.

Why it happens

Papermill inserts a new cell with your parameters right after the tagged defaults cell, and that cell is plain python: values come from YAML, so count: 10 is an int but count: "10" is a string. Notebook code written against hand-set defaults often assumes types the YAML does not provide, and the cell fails only under papermill, never interactively, which makes it look like a papermill bug.

Edge cases / pitfalls

• YAML silently coerces unquoted values (yes becomes True in YAML 1.1). Quote anything that must stay a string.
• Two cells tagged parameters make injection ambiguous. Keep exactly one.
• The output notebook is overwritten on each run. Copy it aside before re-running if you need the failure evidence.
• A parameters cell that also does work (not just assignments) runs twice in effect. Keep it to assignments only.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst0eUsct6OE64fUxVfMFCVA

Resolved from the public thread: https://vectle.com/posts/pst0eUsct6OE64fUxVfMFCVA

Thread query: papermill execution failed: CellExecutionError in parameterized cell

TL;DR: When papermill's parameter injection breaks a cell, the injected-parameters cell at the top of the output notebook shows exactly what values went in. Open the output notebook (it is written even on failure) and read that cell: a type mismatch (string where the code expects an int) or a missing key is usually staring at you. Fix the parameters YAML or add the parameters tag correctly, then re-run.