jupyter-server / pycrdt-websocket Goto Github PK

Right now, get_room will create an instance of a YRoom if the room doesn't exist. This is problematic for libraries that subclass YRoom, e.g. jupyter-collaboration uses it's own DocumentRoom subclass. The room is created and added to the Websocket Server using the add_room API. This can lead to an unintentional creation of a mix of YRoom and DocumentRoom instances.

Problem

Currently, ystores are part of pycrdt-websocket, but they are transport-agnostic and should be used for other transports than WebSockets.

Proposed Solution

Move the ystores to a new repository, pycrdt-store.

Adding an issue to track some follow-up work mentioned here: #33 (comment)

The intent here is to handle exception where they happen, rather than outer layers. In this case, the exception could handle in a Ystore, but it wouldn't be handled until the YRoom catches the exception. We should follow the exception_handler pattern introduced in #31 to handle exceptions in the YRoom.

When using pycrdt-websocket 0.13.1, file access in jupyterlab can hang.

Error logs shows that when ystore.read() method is called before ystore db initialization finishes, it is waiting on an old Event created in __init__ method and ystore.start() method has assigned a new Event. And the old Event() is never set hence file access is blocked.

Error Logs:

[I 2024-05-02 11:10:30.558 ServerApp] Creating new notebook in /TestRTC2
[I 2024-05-02 11:10:30.988 ServerApp] Request for Y document 'TestRTC2/Untitled62.ipynb' with room ID: e6db9699-d261-481e-a188-d76652c290b8
[I 2024-05-02 11:10:31.329 YDocExtension] Creating FileLoader for: TestRTC2/Untitled62.ipynb
initialize ystore, self.db_initialized=<anyio._backends._asyncio.Event object at 0x7ff5a83355a0>
[I 2024-05-02 11:10:31.332 YDocExtension] Watching file: TestRTC2/Untitled62.ipynb
[I 2024-05-02 11:10:31.337 ServerApp] Initializing room json:notebook:e6db9699-d261-481e-a188-d76652c290b8
read data, self.db_initializer=<anyio._backends._asyncio.Event object at 0x7ff5a83355a0>
starting initialize db, self.db_initialized=<anyio._backends._asyncio.Event object at 0x7ff5a8335a80>
ended initialize db, self.db_initialized=<anyio._backends._asyncio.Event object at 0x7ff5a8335a80>

We can see that read data, self.db_initializer=<anyio._backends._asyncio.Event object at 0x7ff5a83355a0> is waiting on an old Event which is never set. Since after start method is called, self.db_initialized is replaced with a new Event.

starting initialize db, self.db_initialized=<anyio._backends._asyncio.Event object at 0x7ff5a8335a80>
ended initialize db, self.db_initialized=<anyio._backends._asyncio.Event object at 0x7ff5a8335a80>