Jupyter notebook can't open the dir named "checkpoints"

[yemq3]

Jupyter Lab can't open it too.
It seems that the back-end didn't return anything.

[kevin-bates]

Hi @yemq3 - thank you for opening this issue. You're probably best off renaming your 'checkpoints' directory if that's possible.

tl;dr: This is an issue and is caused by an ambiguity in the REST API path to handler mappings in the contents service and, likely, can only be addressed via changes to the checkpoints and trust endpoints (or documenting these directory names are "reserved" within the notebook directories).

(I got a little involved looking into this, sorry for the long response.)

This is an issue and is caused by an ambiguity in the REST API path to handler mappings in the contents service:

notebook/notebook/services/contents/handlers.py

Lines 320 to 327 in 7866742

	default_handlers = [
	(r"/api/contents%s/checkpoints" % path_regex, CheckpointsHandler),
	(r"/api/contents%s/checkpoints/%s" % (path_regex, _checkpoint_id_regex),
	ModifyCheckpointsHandler),
	(r"/api/contents%s/trust" % path_regex, TrustNotebooksHandler),
	(r"/api/contents%s" % path_regex, ContentsHandler),
	(r"/api/notebooks/?(.*)", NotebooksRedirectHandler),
	]

As you can see, a path of /api/contents/checkpoints conflicts with both the CheckpointsHandler and ContentsHandler. Since the CheckpointsHandler support GET requests, it is called to satisfy the request - which is supposed to return the checkpoints associated with the endpoint's prefix (which is typically a notebook file). Since the "notebook file" is a directory, in this case, there is no corresponding checkpoint file, so an empty list is returned.

I also see the path from the notebook-dir updated in the Notebook UI as if the user is in the checkpoints directory (probably due to the successful return although from the unexpected endpoint), yet the filesystem display shows them remaining at the checkpoints' parent directory and confusion reigns.

You'll also notice a similar ambiguity with the trust endpoint. However, because TrustNotebooksHandler handler doesn't support GET requests (only POST), it's behavior is slightly different. Attempting to navigate to a trust directory results in the (Notebook) UI displaying as if its actually in the trust directory, yet any files in the actual directory are not display - probably due to the exception that the server throws indicating that the GET method is not supported:

I'm not finding other issues mentioning this but it strikes me as an issue that should be fixed or handled in a better manner - or perhaps we just document that sub-directories named 'checkpoints' and 'trust' are reserved within the notebook-dir hierarchy and shouldn't be used. The trick to fixing this would be to address it in a way so as to not require changes to the endpoints and I don't think that could be done in a reliable manner. As a result, updating the endpoints for the CheckpointsHandler and TrustNotebooksHandler is probably the best option.

Not sure what other applications hit the checkpoint and trust endpoints, but they would be impacted by an endpoint change as well - so these kinds of changes are dicey - and a doc update is probably the safest approach.

Any takers?

[arinzea]

Jupyterlab still cannot open directories with the name 'checkpoints'

[lorelupo]

Up

[kevin-bates]

We discussed this in today's Jupyter Server meeting and felt this issue belonged in that repository to go along with the corresponding pull request.

[kevin-bates]

@meeseeksdev please migrate to jupyter-server/jupyter_server

[lumberbot-app]

Done as jupyter-server/jupyter_server#950.