jupyter-remote-desktop-proxy icon indicating copy to clipboard operation
jupyter-remote-desktop-proxy copied to clipboard

Initial websocket request can fail

Open consideRatio opened this issue 1 year ago • 3 comments

I've not been able to pinpoint the reason, but it seems like the initial attempt to connect to a VNCserver via websockets when visiting /desktop can sometimes fail. I suspect its a race condition that may make it never happen in some contexts, and often in others.

In #101 there is now a test that often but not always in our CI system on the first attempt, but not the second.

Debugging

  • I've not reproduced this by visiting /desktop on my laptop for tiger or turbo, but I think it does from my desktop computer
  • Reproduced using dockerspawner, as seen on the fourth attempt in this GIF: sometimes fails on startup

consideRatio avatar Mar 30 '24 06:03 consideRatio

Ideas on why

  1. viewer.js client sends a websocket handshake before websockify is ready to listen
  2. websockify receives a websocket handshake before vncserver is ready to listen
  3. jupyter-server-proxy's issue https://github.com/jupyterhub/jupyter-server-proxy/issues/459 behavior of accepting the client/proxy websocket handshake before the proxy/server handshake.

consideRatio avatar Apr 02 '24 08:04 consideRatio

I've seen this show up more consistently when the ping is notable (by testing against a hub deployed in USA from Sweden). Three out of three tests made this happen on first attempt to visit /desktop, while doing things locally I just observed it one out of four for example.

consistent-reproduction-remote

consideRatio avatar Apr 02 '24 10:04 consideRatio

@consideRatio I ran into this issue while working on https://github.com/NASA-IMPACT/veda-jupyterhub/issues/2. I have opened a PR with a proposed workaround in #112. Please let me know if that looks reasonable.

sunu avatar May 31 '24 09:05 sunu