Kernel interrupt_mode "message" sends interrupt_request on shell channel instead of control channel

[mntss]

Applies To

• Notebooks (.ipynb files)
• Interactive Window and/or Cell Scripts (.py files with #%% markers)

What happened?

Description

When a kernel has interrupt_mode set to 'message', the extension incorrectly sends the interrupt_request message on the shell channel instead of the control channel as specified by the Jupyter protocol.

Expected Behavior

According to the Jupyter kernel spec documentation:

In case a kernel can not catch operating system interrupt signals (e.g. the used runtime handles signals and does not allow a user program to define a callback), a kernel can choose to be notified using a message instead. For this to work, the kernels kernelspec must set interrupt_mode to message. An interruption will then result in the following message on the control channel:

The interrupt request should:

1. Be created with channel: 'control'
2. Be sent via sendControlMessage()

Actual Behavior

The current implementation (rawKernelConnection.node.ts):

1. Creates message with channel: 'shell'
2. Sends via sendShellMessage()

This causes two problems:

1. The interrupt is queued behind other shell messages - The shell channel processes messages sequentially, so if there are pending execution requests or other shell messages, the interrupt will wait in the queue instead of being processed immediately. This defeats the purpose of interrupting, as the kernel continues executing while the interrupt waits.
2. Interrupt may fail entirely - Kernels expect interrupt_request on the control channel and may ignore or reject it on the shell channel.

VS Code Version

1.105.1

Jupyter Extension Version

2025.9.1

Jupyter logs

Coding Language and Runtime Version

No response

Language Extension Version (if applicable)

No response

Anaconda Version (if applicable)

No response

Running Jupyter locally or remotely?

None