Open hpvb opened 2 years ago
This is related to https://github.com/jupyter-widgets/ipywidgets/issues/3580
From our dev discussion in our dev meeting today:
Thank you! For now my local workaround works (a wonderful sed hack in the Dockerfile) but a proper fix would be very nice!
Thank you! For now my local workaround works (a wonderful sed hack in the Dockerfile) but a proper fix would be very nice!
@hpvb, just wondering how you've hacked this for now as I am having the exact issue. How exactly are you editing the CONTROL_COMM_TIMEOUT value?
@jasongrout - sounds encouraging.
For some extra context, @ollyhensby and I are working on quite a large / complex application. It works fine in JupyterLab but we get this issue in Voila. To make matters worse - it only happens sometimes! Most of the time the app works fine, but on occasion it is blank on loading (i guess depending on usage). Would be great to see a fix.
Do you also see "Comm is already created" as I mention in https://github.com/jupyter-widgets/ipywidgets/issues/3580#issue-1357330645 ?
Hi @maartenbreddels, I am getting this in the console log.
Just to add @maartenbreddels, we've got around this issue for now by removing initial loading of some widgets and instead have them load when observed e.g. we have tabs where when a tab is clicked on, the widgets within it load upon the tab being selected.
Doing this we therefore load a lot less widgets upon initialising and avoid the error shown above.
This is voila 0.4.0, so that means from https://github.com/voila-dashboards/voila/blob/0.4.x/packages/voila/package.json
We are using https://github.com/jupyter-widgets/ipywidgets/blame/511663a56324cea5324f49a65ebe25e2f1b04d87/packages/base-manager/src/manager-base.ts#L382 which hasn't change for 2 years, so that is likely the code that you are running.
I think there is an issue in the protocol as it now is (I discussed this with @mariobuikhuizen a while ago when analyzing this because of a different bug). IIRC, we suggested back then (private communication) that we should change the protocol such that when the comm is opened, the kernel sends back an 'acknowledge' message first, after which we should ignore the timeout. Now we do not know if the kernel supports the control comm or not, and let the timeout logic assume that. After the acknowledge, we should just wait for the data.
@martinRenou IIRC there is a proposal somewhere to put this in the Comm protocol, is that right?
In Solara server we take a different approach, where we only start running the Python code when the client is connected, avoiding this issue.
Yes, that is a good workaround and idea in general. You might be interested in Reacton, which will automatically create and destroy widgets for you in such a situation. It does require investing a bit into learning to think like React (in Python)
The exact console warning that OP reports shows up for me when creating a new notebook in a new environment with only jupyterlab, jupyterlab-widgets, and their dependencies installed. No idea if the same cause, but it doesn't take a complicated notebook to get the warning.
Chrome 120.0.6099.234 anyio 4.2.0 argon2-cffi 23.1.0 argon2-cffi-bindings 21.2.0 arrow 1.3.0 asttokens 2.4.1 async-lru 2.0.4 attrs 23.2.0 Babel 2.14.0 backcall 0.2.0 beautifulsoup4 4.12.3 bleach 6.1.0 certifi 2023.11.17 cffi 1.16.0 charset-normalizer 3.3.2 comm 0.2.1 debugpy 1.8.0 decorator 5.1.1 defusedxml 0.7.1 exceptiongroup 1.2.0 executing 2.0.1 fastjsonschema 2.19.1 fqdn 1.5.1 idna 3.6 importlib-metadata 7.0.1 importlib-resources 6.1.1 ipykernel 6.29.0 ipython 8.12.3 isoduration 20.11.0 jedi 0.19.1 Jinja2 3.1.3 json5 0.9.14 jsonpointer 2.4 jsonschema 4.21.1 jsonschema-specifications 2023.12.1 jupyter_client 8.6.0 jupyter_core 5.7.1 jupyter-events 0.9.0 jupyter-lsp 2.2.2 jupyter_server 2.12.5 jupyter_server_terminals 0.5.1 jupyterlab 4.0.11 jupyterlab_pygments 0.3.0 jupyterlab_server 2.25.2 jupyterlab-widgets 3.0.9 MarkupSafe 2.1.3 matplotlib-inline 0.1.6 mistune 3.0.2 nbclient 0.9.0 nbconvert 7.14.2 nbformat 5.9.2 nest-asyncio 1.5.9 notebook_shim 0.2.3 overrides 7.4.0 packaging 23.2 pandocfilters 1.5.1 parso 0.8.3 pexpect 4.9.0 pickleshare 0.7.5 pip 23.3.2 pkgutil_resolve_name 1.3.10 platformdirs 4.1.0 prometheus-client 0.19.0 prompt-toolkit 3.0.43 psutil 5.9.8 ptyprocess 0.7.0 pure-eval 0.2.2 pycparser 2.21 Pygments 2.17.2 python-dateutil 2.8.2 python-json-logger 2.0.7 pytz 2023.3.post1 PyYAML 6.0.1 pyzmq 25.1.2 referencing 0.32.1 requests 2.31.0 rfc3339-validator 0.1.4 rfc3986-validator 0.1.1 rpds-py 0.17.1 Send2Trash 1.8.2 setuptools 41.6.0 six 1.16.0 sniffio 1.3.0 soupsieve 2.5 stack-data 0.6.3 terminado 0.18.0 tinycss2 1.2.1 tomli 2.0.1 tornado 6.4 traitlets 5.14.1 types-python-dateutil 2.8.19.20240106 typing_extensions 4.9.0 uri-template 1.3.0 urllib3 2.1.0 wcwidth 0.2.13 webcolors 1.13 webencodings 0.5.1 websocket-client 1.7.0 zipp 3.17.0
Description
We are running some rather complicated notebooks using voila. They work fine when testing locally but when deployed to a remote server they stop working, and we see the following message in the browser log:
Failed to fetch ipywidgets through the "jupyter.widget.control" comm channel, fallback to fetching individual model state. Reason: Control comm did not respond in time
I eventually traced this down to the value of CONTROL_COMM_TIMEOUT, by manually changing this to a much higher value the notebooks work as expected. There doesn't appear to be a way to do this from configuration however.
Reproduce
Start a complicated notebook over an internet connection.
I set a breakpoint on the error being printed and worked my way backwards. Manually changed the
4e3
to4e8
in the compiled javascript and the problem went awayExpected behavior
I expect the control channel to be retried, perhaps an exponential backoff to a larger value, or ideally a way to just increase the value as a site specific setting.
Context
Troubleshoot Output
Command Line Output
Browser Output
If using JupyterLab
Installed Labextensions