-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pass launch_instance args on correctly. #4039
Conversation
Thanks for submitting your first pull request! You are awesome! 🤗 |
(Contrary to the automated advice above, the Pull Request Template appears to be empty). |
Note, older versions (JupyterHub 2.3.1) do pass # JupyterHub 2.3.1 app.py
3300 @classmethod
3301 def launch_instance(cls, argv=None):
3302 self = cls.instance()
3303 self._init_asyncio_patch()
3304 loop = IOLoop.current()
3305 task = asyncio.ensure_future(self.launch_instance_async(argv)) # <------- HERE
... |
Thanks! Added a test to make sure we don't reintroduce similar bugs. Will do a 3.0.1 pretty soon after some more 3.0 feedback. |
We upgraded JupyterHub to 3.0.0 but the container with jupyter-singleuser 3.0.0 sessions spawened by the batchspwaner fail to callback to the hub and the session is stuck in pending. It works fine with jupyter-singleuser 2.3.1 sessions tough.
|
@timeu I am experiencing a similar issue. Did you manage to fix it? |
pinning jupyter-singleuser to < 3.0.0 or upgrading to the latest jupyterhub (>=4.0.0) fixed our issue |
@timeu Thanks for the prompt reply. That doesn't seem working for me. I am running jupyterhub 4.0.0 and jupyterhub-singleuser 4.0.0. |
#251 fixed my issue. 🥇 |
Greetings JupyterHub experts. Thanks for your excellent software!
Tentative bug fix:
I think the hub
launch_instance
class method should be passing its args on tolaunch_instance_async
(?), but currently it is passing them toloop.run_sync
which is expecting a timeout value there.