JupyterLab manager: widget model not found

[jtpio]

Running from the master branch and following these steps:

• Turn on: "Save Widget State Automatically"
• Close the notebook
• Shut down the kernel
• Refresh the page
• Open the same notebook
• Execute the cells

It looks like the widget manager is unable to recreate the widgets after re-executing the cells:

[jtpio]

Actually it looks like this happens when the first notebook is opened after a page reload, regardless of whether the widget state is saved or not:

[jtpio]

Digging into that a little bit: it looks like _handleCommOpen is not reached on subsequent widget creation:

ipywidgets/packages/jupyterlab-manager/src/manager.ts

Lines 435 to 443 in 7cb20cd

	// _handleCommOpen is an attribute, not a method, so `this` is captured in a
	// single object that can be registered and removed
	protected _handleCommOpen = async (
	comm: Kernel.IComm,
	msg: KernelMessage.ICommOpenMsg
	): Promise<void> => {
	const oldComm = new shims.services.Comm(comm);
	await this.handle_comm_open(oldComm, msg);
	};

Which should be where models are created and registered:

ipywidgets/packages/base-manager/src/manager-base.ts

Line 191 in 28ab143

return this.new_model(

[jtpio]

Stepping into the code a bit more: it looks like several connections to the kernel are established from the document context when the notebook is open for the first time and the kernel is not running yet.

However at some point, this.handleComms ends up being false here:

https://github.com/jupyterlab/jupyterlab/blob/75422e60eb4ae0af5036c4b7bc31addf9cdfc9ef/packages/services/src/kernel/default.ts#L830

At the time when the first kernelChanged signal is emitted here:

ipywidgets/packages/jupyterlab-manager/src/manager.ts

Line 551 in 28ab143

this._handleKernelChanged(args);

Which would explain why the comm target is not registered.

[jasongrout]

For context:

1. The first time a kernel is started, the help menu starts up a kernel connection to get the help links from the kernel info, as well as the actual document. So there should be two kernel connections, and then the help menu connection is disposed after the info comes in.
2. In general, only one connection should be able to handle comms. When creating a new connection, it checks to see if any other connection handles comms, and if another connection handles comms, the default is to not handle comms.

So perhaps the help menu is somehow connecting first, before the document? I haven't seen that, and thought it would not happen.

Regardless, it looks like there is no way when creating a session connection to say that the kernel connection should not handle comms. I think the session connection should have a new initialization argument for the kernel connection options, so that the help menu can specify that its kernel connection does not handle comms ever.

[jasongrout]

@jtpio - JupyterLab 2.0b3, released today, has a jupyterlab/jupyterlab#7820, which should solve the issue I mention above, if that is the problem that you are seeing. Can you check with JLab 2.0b3?

[jtpio]

Thanks @jasongrout, just tried with the latest alpha and it looks like it fixes it!

[jtpio]

2. In general, only one connection should be able to handle comms. When creating a new connection, it checks to see if any other connection handles comms, and if another connection handles comms, the default is to not handle comms.

Right, this seems to be where this check is happening:

https://github.com/jupyterlab/jupyterlab/blob/3cb64ca6885358e7f9623f518518bb3f9de017bc/packages/services/src/kernel/manager.ts#L113-L122

[jtpio]

Closing as fixed in JupyterLab 2.0b3 by jupyterlab/jupyterlab#7820.