I ran into the following exception when running a Notebook inside VSCode with the python environment running on a remote machine (through the VSCode tunnel). The remote machine has a distributed file system which can cause significant latencies when starting a notebook from scratch, which can unearth race conditions that would be unlikely on a normal laptop or desktop machine. I guess our somewhat offbeat use case is the reason this did not get noticed before.
ERROR:tornado.general:Uncaught exception in ZMQStream callback
Traceback (most recent call last):
File "/apps/gent/RHEL9/cascadelake-ib/software/IPython/9.14.0-GCCcore-15.2.0/lib/python3.14/site-packages/traitlets/traitlets.py", line 651, in get
value = obj._trait_values[self.name]
~~~~~~~~~~~~~~~~~^^^^^^^^^^^
KeyError: '_control_lock'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/apps/gent/RHEL9/cascadelake-ib/software/PyZMQ/27.1.0-GCCcore-15.2.0/lib/python3.14/site-packages/zmq/eventloop/zmqstream.py", line 565, in _log_error
f.result()
~~~~~~~~^^
File "/apps/gent/RHEL9/cascadelake-ib/software/jupyter-server/2.19.0-GCCcore-15.2.0/lib/python3.14/site-packages/ipykernel/kernelbase.py", line 347, in dispatch_control
async with self._control_lock:
^^^^^^^^^^^^^^^^^^
File "/apps/gent/RHEL9/cascadelake-ib/software/IPython/9.14.0-GCCcore-15.2.0/lib/python3.14/site-packages/traitlets/traitlets.py", line 706, in __get__
return self.get(obj, cls) # type:ignore[return-value]
~~~~~~~~^^^^^^^^^^
File "/apps/gent/RHEL9/cascadelake-ib/software/IPython/9.14.0-GCCcore-15.2.0/lib/python3.14/site-packages/traitlets/traitlets.py", line 668, in get
value = self._validate(obj, default)
File "/apps/gent/RHEL9/cascadelake-ib/software/IPython/9.14.0-GCCcore-15.2.0/lib/python3.14/site-packages/traitlets/traitlets.py", line 741, in _validate
value = self.validate(obj, value)
File "/apps/gent/RHEL9/cascadelake-ib/software/IPython/9.14.0-GCCcore-15.2.0/lib/python3.14/site-packages/traitlets/traitlets.py", line 2319, in validate
self.error(obj, value)
~~~~~~~~~~^^^^^^^^^^^^
File "/apps/gent/RHEL9/cascadelake-ib/software/IPython/9.14.0-GCCcore-15.2.0/lib/python3.14/site-packages/traitlets/traitlets.py", line 850, in error
raise TraitError(e)
traitlets.traitlets.TraitError: The '_control_lock' trait of an IPythonKernel instance expected a Lock, not the NoneType None.
This was with ipykernel v7.2.0 on Redhat Linux 9 (remote machine, HPC infrastructure). I've written a patch for v7.2.0, so we can perform a minimal upgrade of our teaching setup:
https://github.com/tovrstra/ipykernel/tree/bugfix/control_lock_race
I think the same issue (_control_lock created too late) is still present in the main branch. I'll make a PR on the main branch in minute.
I ran into the following exception when running a Notebook inside VSCode with the python environment running on a remote machine (through the VSCode tunnel). The remote machine has a distributed file system which can cause significant latencies when starting a notebook from scratch, which can unearth race conditions that would be unlikely on a normal laptop or desktop machine. I guess our somewhat offbeat use case is the reason this did not get noticed before.
This was with ipykernel v7.2.0 on Redhat Linux 9 (remote machine, HPC infrastructure). I've written a patch for v7.2.0, so we can perform a minimal upgrade of our teaching setup:
https://github.com/tovrstra/ipykernel/tree/bugfix/control_lock_race
I think the same issue (
_control_lockcreated too late) is still present in the main branch. I'll make a PR on the main branch in minute.