Running a Chatbook cell throws an uncaught "No active debugger session" error

[pjdoland]

Summary

Running any cell in a Chatbook raises an uncaught Error: No active debugger session in the browser. It appears once when the confirm bar is shown and again after Run. The cell itself works: code is generated, runs, and shows its output. The cost is an unhandled error on every Chatbook run, which shows up in the devtools console and in any error reporting that watches for uncaught exceptions.

Reproduction

1. Install NBI 6.0.0 from PyPI (JupyterLab 4.6.4).
2. Open a new Chatbook from the launcher.
3. Type any prompt with no @ mentions, for example Say hello, and press Shift Enter.
4. Watch the browser console. No active debugger session is thrown when the confirm bar appears, and again after clicking Run.

Opening a Chatbook without running anything produces no error. I also reproduced this on the #505 branch; that change does not touch execution.

Stack

Error: No active debugger session
    at h.displayModules (jlab_core...js)
    at d (jlab_core...js)                 <- Signal.emit
    at e.emit / o.emit
    at l (jlab_core...js)
    ...
    at l.onAnyMessage (jlab_core...js)    <- KernelConnection anyMessage

What I found

• In JupyterLab 4.6.4, @jupyterlab/debugger's DebuggerHandler listens to the session's anyMessage. On every received execute_reply it emits executionDone (packages/debugger/src/handler.ts, around line 193).
• @jupyterlab/debugger-extension connects that signal straight to displayModules (packages/debugger-extension/src/index.ts, lines 129, 236 and 342), and DebuggerService.displayModules() throws No active debugger session when there is no session (packages/debugger/src/service.ts, around line 406).
• The Chatbook kernel does not claim debugger support. kernelspec/kernel.json sets "debugger": false, and a live kernel_info_reply from the chatbook kernel has no debugger field. The child backend kernel's IOPub relay (_IOPUB_RELAY_TYPES in chatbook_kernel/backend.py) does not forward debug_event either. So the error is not the debugger reacting to debug traffic; it is the execute_reply path calling displayModules with no session.

Open question

I did not establish whether this happens for every kernel without debugger support, which would make it a JupyterLab issue that Chatbook merely exposes, or whether something about the Chatbook notebook causes the handler to be attached to a kernel it should have skipped. A quick way to tell would be the same steps with another kernel that has no debugger support. If it is JupyterLab-wide, the fix belongs upstream: guard displayModules or skip executionDone when no session exists. Otherwise it is worth checking how the debugger handler decides to attach to the Chatbook panel.

Environment

NBI 6.0.0 (PyPI), JupyterLab 4.6.4, Python 3.12, macOS, headless Chromium 151. The failure does not depend on the model or on mentions.

[pjdoland]

This turned out to be a JupyterLab issue that Chatbook happens to expose, rather than something in NBI.

Since JupyterLab 4.6.0 (jupyterlab/jupyterlab#18081), every execute_reply triggers a Kernel Sources refresh through DebuggerService.displayModules(). That call throws "No active debugger session" whenever no debugger session exists. A session only exists once a notebook with a debug-capable kernel has been opened, so the error appears with any kernel that does not declare debugger support. I reproduced it with a plain ipykernel kernelspec marked "debugger": false, with no NBI installed.

Upstream:

• Issue: Running a cell with a kernel without debugger support raises "No active debugger session" jupyterlab/jupyterlab#19936
• Fix (draft PR): Do not request kernel sources when the debugger is not started jupyterlab/jupyterlab#19937

With that fix, a Chatbook cell on NBI 6.1.0 runs without the error. Nothing needs to change in NBI. The error should go away once a JupyterLab release includes the fix.

[pjdoland]

@mbektas Fixed upstream in JupyterLab: jupyterlab/jupyterlab#19937 was merged into main and backported to 4.6.x (jupyterlab/jupyterlab#19957). The fix is not in a release yet (the latest is 4.6.4), so the error will go away with the next 4.6.x release. Nothing needs to change in NBI, so I am closing this.