Handle missing status field in execute_reply from XEUS-based kernels#14374
Handle missing status field in execute_reply from XEUS-based kernels#14374ChrisJefferson wants to merge 3 commits intoquarto-dev:mainfrom
Conversation
XEUS-based Jupyter kernels (such as the Maple 2025 kernel) omit the
'status' field from execute_reply messages when execution produces an
error. This violates the Jupyter messaging protocol, which requires
every execute_reply to include status. The missing field causes a
KeyError that crashes notebook execution.
This is a workaround for a kernel-side protocol violation — the right
fix is in the kernel. But the workaround is low-risk: we catch a
specific KeyError("'status'") around client.execute_cell() and record
it as a cell error output rather than crashing. Kernels that conform
to the protocol are unaffected.
Tested against Maple 2025 (XEUS 2.3.1) with 18 Quarto documents
containing executable Maple code blocks.
|
Thanks for report and fix.
Do you have a list of other Xeus based kernel we could look at testing ? I would like to maybe add a test for this in our codebase, and we would need an open working kernel. |
e.args tuple comparison survives any upstream change to KeyError message formatting, which str(e) equality would silently miss. The cell source in the synthetic traceback field was redundant with the rendered output — the source is already shown next to the error block — and inflated error output for large cells. Traceback entries are conventionally stack frames, not source dumps. The kernel-deps cleanup_cell execute_cell call has the same exposure: any XEUS-based Python kernel (e.g. xeus-python) would hit it via cleanup.py. Guarded symmetrically but non-fatally, since cleanup failures shouldn't abort the render.
XEUS's create_error_reply / create_successful_reply helpers in xhelper.cpp always set status, and the mainstream XEUS-based kernels (xeus-python, xeus-r) go through those helpers — their execute_reply messages are conforming. The omission is specific to kernel authors who bypass the helpers or use an older XEUS. Maple 2025 is the only one currently known to do that. The previous wording implied every XEUS-based kernel was at risk, which would misdirect users of conforming kernels.
|
Looked into XEUS itself to answer the question — this is kernel-specific, not XEUS-framework-wide. Why xeus-python and xeus-r are not affectedXEUS has helpers that always set Both xeus-python and xeus-r go through these helpers: So a conforming XEUS kernel produces TestingA smoke-all test with xeus-python or xeus-r won't exercise the guard. The cleanest path would be a mocked unit test against I'll merge once CI is green. |
2 participants
XEUS-based Jupyter kernels (such as the Maple 2025 kernel) omit the 'status' field from execute_reply messages when execution produces an error. This violates the Jupyter messaging protocol, which requires every execute_reply to include status. The missing field causes a KeyError that crashes notebook execution.
This is a workaround for a kernel-side protocol violation — the right fix is in Maple 2025, but I think it's useful to fix (I assumed, incorrectly, it was quarto's fault at first, and the error message is very confusing). But the workaround is low-risk: we catch a specific KeyError("'status'") around client.execute_cell() and record it as a cell error output rather than crashing. Kernels that conform to the protocol are unaffected.
Tested against Maple 2025 (XEUS 2.3.1) with 18 Quarto documents containing executable Maple code blocks. I think this might effect other XEUS based kernels, not just Maple (although I haven't tested them).