Jupyterlab (Kubernetes) + Prodigy: "ERROR: Can't fetch project. Make sure the server is running correctly."


I have JupyterHub running in Kubernetes, and I would like to integrate the jupyterlab-prodigy plugin. In my JupyterHub setup each user's workspace is started in its own pod. I have configured the reverse proxy to forward all incoming requests on an endpoint of the form https://mydomain.com/prodigy/ to http://POD_IP:8080. However when I start the prodigy I get this error:

I am able to get JSON responses when I query the /get_questions and /project endpoints.

I also read that this maybe caused by an outdated version of the murmurhash library but I am using 1.0.2 with prodigy 1.9.6, so I don't think that's the issue.

Any ideas?

Hi! This error happens on the very first request, so it's possible the problem is with the API/API access (since it starts and serves the app, but then can't make the request).

If you open your browser's developer tools, do you see a request error there? Maybe it's a CORS thing? Otherwise, is there any traceback in the terminal?

Hey Ines,

Thanks for the pointers. After looking at the console in Dev Tools I've discovered that the prodigy server is somehow reconstructing the url for the /project and /fonts endpoints. Basically the route I have configured in the proxy for the prodigy server is

https://jhub.mydomain.com/user/my_username/prodigy/ -> http://MY_POD_IP:8080

thus, in order to access the /project and /fonts endpoints, the URLs should look like:


however from the 404 errors in Dev Tools it looks like Prodigy is trying to access these endpoints at:


This actually makes sense. However, why is Prodigy loosing the URL prefix?

It seems like the /hub/ part of the URLs in my previous response just gets appended by the proxy when its doesn't have the route, so the Prodigy server is trying to query


completely dropping the prefix in the path. Hope this is helpful.

Yes, the path prefix is the problem here. We currently don't have a satisfying solution for modifying the paths, so subdomain-based routing is the easiest solution.

@honnibal explained this in more detail here: