Publishing skips a QTI item whose DOCTYPE declares an entity instead of failing the channel

[rtibblesbot]

❌ This issue is not open for contribution. Visit Contributing guidelines to learn about the contributing process and how to find suitable issues.

Target branch: unstable

Observed behavior

validate_qti_item raises lxml.etree.XMLSchemaValidateError: Internal error in XML Schema validation. on an item with an internal-subset entity declaration that the body references.
QTIExerciseGenerator._create_native_qti_item does not catch it, and create_exercise_archive runs the item loop without a try, so it propagates out of the publish.
Every other invalid item is logged and excluded from the package.

Errors and logs

>>> validate_qti_item('<!DOCTYPE qti-assessment-item [<!ENTITY e "zz">]><qti-assessment-item xmlns="http://www.imsglobal.org/xsd/imsqtiasi_v3p0" identifier="i" title="t" adaptive="false" time-dependent="false"><qti-item-body><p>&e;</p></qti-item-body></qti-assessment-item>')
lxml.etree.XMLSchemaValidateError: Internal error in XML Schema validation.

Expected behavior

The item is reported invalid, logged, and left out of the package like any other schema failure. The rest of the channel publishes.

User-facing consequences

One stored type == qti item (ricecooker upload or direct sync write; the parser comment in validation.py treats this input as untrusted) blocks publishing the whole channel.

Steps to reproduce

1. Store the XML above as raw_data of a qti AssessmentItem on an exercise.
2. Publish the channel.
3. Publish fails with XMLSchemaValidateError.

Context

• contentcuration/contentcuration/utils/assessment/qti/validation.py validate_qti_item
• Found reviewing Multi-answer text-entry QTI items saved before #6223; reproduces on upstream/unstable and is not caused by that branch.

AI usage

I used Claude Code to review the #6223 branch and reproduce this against upstream/unstable with validate_qti_item. I did not run a full publish; the propagation through create_exercise_archive is read from the code.

[rtibblesbot]

Plan: validate_qti_item returns an invalid result, instead of raising, for an item whose DOCTYPE declares an entity the body references, so publish excludes the item and continues.

• Report schema-validation crashes as invalid items
• Self-review the produced code

Assumptions — the issue did not settle these; say so if one is wrong.

• Not reproduced: lxml is not installed in the planning sandbox, so the failure mode is taken from the issue; if it raises elsewhere, the catch moves there.
• Catch etree.XMLSchemaValidateError only; if other lxml errors surface from validate, widen to etree.LxmlError.
• Items with a DOCTYPE but no entity reference keep validating; if maintainers want DOCTYPE banned, it becomes an up-front check and some stored items flip to invalid.
• The reported message is lxml's generic "Internal error in XML Schema validation." (or error_log if populated); if a clearer editor-facing message is wanted, add an explicit entity check.

---

@rtibblesbot's comments are generated by an LLM, and should be evaluated accordingly

How was this generated?

• Implemented code following the pre-approved plan using test-driven development (red-green-refactor)
• Ran the project's full test suite and linter before committing
• For UI changes: captured live screenshots to verify rendering
• For backend changes: verified with example API/CLI output

[rtibblesbot]

AlexVelezLl Blocked — these cannot be assumed either way:

• Publish still aborts on an entity-bearing QTI item: _node_is_perseus_derivable (publish.py:270) → perseus_derive._parse raises ValueError from etree.QName(entity_node) before the validator runs. Fixing it means editing perseus_derive.py (and a publish-path test), outside this branch's four-file scope. Widen scope to perseus_derive.py, or land it as a separate issue?

---

@rtibblesbot's comments are generated by an LLM, and should be evaluated accordingly

How was this generated?

• Implemented code following the pre-approved plan using test-driven development (red-green-refactor)
• Ran the project's full test suite and linter before committing
• For UI changes: captured live screenshots to verify rendering
• For backend changes: verified with example API/CLI output

[AlexVelezLl]

Duplicate of #6234; fixed by #6238.