Per-cell execution timeout remains absent in JupyterLab 4.x despite kernel interruption and idle culling mechanisms

Short answer

No. JupyterLab 4.x with Jupyter Server 2.x does not enforce a maximum wall-clock time for an individual cell. cull_idle_timeout, cull_interval, and cull_connected manage kernel lifecycle; they do not interrupt code that is actively executing. The interrupt_request message exists in the protocol, but whether it stops a cell depends on the kernel, so there is no cross-kernel per-cell timeout built into JupyterLab 4.x.

Confirmed facts versus likely explanation

Confirmed facts

• Jupyter Server culling settings apply to kernels, not to individual executions.
• cull_connected concerns a kernel with an active frontend connection but no recent execution; a cell currently running is not idle merely because it emits no output.
• IPython typically converts interrupt_request into KeyboardInterrupt at the next bytecode boundary.
• Native extensions, C/Fortran code, and blocking system calls can ignore or delay that signal, so interruption is not reliable across kernel types.

Likely explanation

Execution happens inside the kernel process, while JupyterLab is a frontend. The frontend cannot enforce a wall-clock deadline without kernel cooperation, an out-of-process supervisor, or kernel restart. No widely adopted message-specification standard is known to define per-cell execution timeouts; treat that as needing review.

Steps for this case

1. Confirm versions: python -m jupyterlab --version and python -m jupyter_server --version. List kernels with jupyter kernelspec list.
2. Inspect server configuration for cull_idle_timeout, cull_interval, and cull_connected. None of these defines a per-cell execution limit.
3. Represent the failure: run time.sleep(300) in an IPython notebook cell, choose Kernel → Interrupt, and confirm execution stops. Repeat with any native extension or blocking call used in production cells.
4. If interrupt works for IPython cells, use IPython-specific timeout tooling only for those cells. For other kernels or blocking calls, plan external wall-clock supervision or accept kernel restart, which loses in-memory state.

Missing diagnostic detail

What is the target kernel language, and do the long-running cells call native extensions or blocking system calls? This determines whether interrupt_request is reliable or whether you need kernel restart or external supervision.

Verification

After any workaround, measure elapsed time from cell start to interruption or restart, and confirm whether in-memory variables survive. Restart-based enforcement should be used only when state loss is acceptable.