Out of band file deletion/permission change does not shut the file watcher

[krassowski]

Description

This is a follow-up to:

• Out of band file deletion results in watch file error #417
• Fix cleanup logic and suppress repetitive error logs #475

Reproduce

1. Create a subclass of ContentsManager
2. Add logs on each get request to a file
3. Start JupyterLab with that subclass
4. Open a file in RTC mode
5. Delete the file using terminal (out of band)
6. See that each second a new request is logged to access said file from

jupyter-collaboration/projects/jupyter-server-ydoc/jupyter_server_ydoc/loaders.py

Lines 231 to 244 in da896e1

	async def maybe_notify(self) -> None:
	"""
	Notifies subscribed rooms about out-of-band file changes.
	"""
	do_notify = False
	filepath_change = False
	async with self._lock:
	path = self.path
	if self._current_path != path:
	self._current_path = path
	filepath_change = True
	# Get model metadata; format and type are not need
	model = await ensure_async(self._contents_manager.get(path, content=False))

Even though jupyter-collaboration itself no longer pollutes the logs (since #475), this is still problematic because hitting the API 1 second for all notebooks deleted in the past from large number of users can lead to a significant noise in logs and potential performance degradation. This is in particular true for non-default contents managers which may have much higher overhead and additional logging.

Expected behavior

We do want to continue watching the file in some way, if a user performs a shuffle like:

mv current.ipynb backup.ipynb
mv old.ipynb current.ipynb

we want to still update the file - thus we cannot just stop watching it; however, if possible we should:

• reduce the frequency of requests (exponential backoff?)
• pause the watches until a file with such a name re-appears on disk

Similarly, if user lost permissions we would ideally be able to listen to file-system events about permission changes.

This is tricky to support because:

• it would need to work across operating systems
• it would need to work with remote contents mangers

We would need to have a way for a jupyter-server ContentsManager to emit events about file system like:

• "a file was created"
• "file permissions changed"

Context

• Operating System and version: Linux
• JupyterLab version: 4.5.0

[krassowski]

we want to still update the file - thus we cannot just stop watching it

Maybe we can stop the watcher if the probability of the file re-appearing is negligible. I suppose something like 7 days would be a sensible default, but we alternatively we could make it configurable and avoid setting a default value at all.

reduce the frequency of requests (exponential backoff?)

If we reduce the interval significantly, then the user may see an unexpected reload (say if it happens a minute after they moved a file, they could be confused and may have added new content to the file since). I think we can increase the interval but only by a factor of two, not by an order of magnitude.

pause the watches until a file with such a name re-appears on disk

I opened jupyter-server/jupyter_server#1580 to discuss it more widely.

[davidbrochart]

I think the real issue is that jupyter-server-fileid doesn't have a file watcher? If it had, there would be no need to poll indefinitely?