Defect: parent points to a block which is not a shared type

[copyfactory]

Thank you for this package, definitely helped me get TipTap/YJS working with my Django app.

I seemed to have come across an error where it seems as though a corrupted document state is being persisted causing both the loading of the document to not work as well as the yroom worker to crash.

Below is the relevant stacktrace:

 app[rtc.1]:  [INFO] yroom.roomsync: Creating new YRoom 'sequence.2868' with data and settings YRoomSettings { protocol_version: V1, name_prefix: true, server_start_sync: false, disable_pipelining: true }
 app[rtc.1]: thread '<unnamed>' panicked at 'Defect: parent points to a block which is not a shared type', /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/yrs-0.16.10/src/block.rs:1492:30
 app[rtc.1]: note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
 app[rtc.1]:   File "/app/.heroku/python/lib/python3.10/site-packages/channels_yroom/worker.py", line 80, in run_consumer
 app[rtc.1]:     await self.consumer.dispatch(message)
 app[rtc.1]:   File "/app/.heroku/python/lib/python3.10/site-packages/channels/consumer.py", line 73, in dispatch
 app[rtc.1]:     await handler(message)
 app[rtc.1]:   File "/app/.heroku/python/lib/python3.10/site-packages/channels_yroom/channel.py", line 71, in message
 app[rtc.1]:     await self.create_room_from_snapshot(room_name, conn_id)
 app[rtc.1]:   File "/app/.heroku/python/lib/python3.10/site-packages/channels_yroom/channel.py", line 61, in create_room_from_snapshot
 app[rtc.1]:     return self.room_manager.connect_with_data(room_name, conn_id, snapshot)
 app[rtc.1]: 2024-03-08 14:52:08,208 [ERROR] channels_yroom.worker: Caught exception: Defect: parent points to a block which is not a shared type
 app[rtc.1]: 2024-03-08 14:52:08,409 [INFO] channels_yroom.worker: Shutting down...

I don't believe there is a way to recover corrupted documents from the saved bytes data?

The only relevant link I found was: https://github.com/y-crdt/ypy/issues/101

Which seems to be referencing a much older version of packages and was from a few years back?

Any ideas that you may have would be appreciated!

Thank you

[stefanw]

I'm not aware of a way to restore the corrupted data. The binary data is intentionally opaque to the Django app.

Here are some thoughts:

• You could try loading the data with a different Y implementation. The Rust implementation yrs that is used is relatively young and has some known bugs in the block implementation (e.g. https://github.com/y-crdt/y-crdt/pull/266)
• Is the data stored correctly? Are you using the database backend? Which database?
• Maybe the storage should only commit if the data can be loaded? However, the snapshot data is coming directly from the ydoc, it should be ok.
• It looks like this is from a production deployment. Could this be a broken/malicious client? The validation story of yjs is pretty poor so maybe a bad client update?
• Looks like the panic is triggered here in the repair function that is called under some condition when integrating an update. I don't know the how the block implementation in yrs works though.