You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I started using Docmost a few days ago and after working on a large doc-tree the tree suddenly disappeared when I tried to move a file and the whole tree was non-recoverable deleted.
When investigating the issue I found the following syncing problems that can occur (not always) when using multiple browser tabs:
Case 1:
Tab1: create tree File1 > File2
Tab2: refresh to sync
Tab2: move File2 on same level as File1
Tab1: delete File1
Tab2: refresh -> File1 & File2 are gone
Tab1: refresh -> File1 & File2 are gone
Case 2:
Tab1: create tree File1 > File2 > File3
Tab2: refresh to sync
Tab2: move File2 > File3 to the same level as File1
Tab1: rename File2 and File3
Tab1: refresh -> the renamed and the moved versions now exist
Case 3:
Tab1: create tree untiteled > untiteled
Tab2: refresh to sync
Tab2: delete inner untiteled
Tab2: create a new inner untiteled -> two untiteled docs are created
These errors may seem forced, but I think this could easily be a serious problem when working with others at the same time on the structure of the documentation. Or if you are just as unlucky as me an have an old unsynced tab that suddenly overwrites your whole doc-tree.
I think that tabs should be forced to resync before they are able to make any changes. I'm currently unaware how this is implemented, but there should be a failsafe mechanism with the last edit time, or a change counter or so which makes it possible to see if the pushed change is outdated or not. And the already requested feature for a bin would be a good place to catch all other cases that might get thou these countermeasures making the errors reversible.
I don't know if your case is similar to mine, but I've started recently to use docmost and had similar issues when using two accounts. In my case docmost is behind an nginx reverse proxy and websockets were disabled. After enabling websockets the synchronization for multiple users worked nicely.
@amamaral you are right that the syncing does not work when websockets are disabled. But thats not really a bug but expected bahaviour, because they are used for syncing.
The bug i mention is rather a problem with the usage of the websockets, because false syncing occures in some situations which deletes Data you already created. And this occures even if syncing is correctly configured and works most of the time.
I had some situation in the v0.3.0, which is a page is added with some content. But the whole page is disappear the next day.
It might be nice to have a sync status icon on the page.
Hi @JohannesFleischer, thank you for the candid observations.
In the current design, the page tree currently has limited syncing capabilities because the child nodes are lazy-loaded. With further efforts, this can be improved.
Case 1
In my tests, "file 2" does not get deleted from the database and appears on refresh. Can you confirm this?
@Philipinho my observations were related to v0.3.1 updating is currently still on my todo list. I can try to reproduce it again in the new version.
On v0.3.1 all of these cases occurred exactly like described above multiple times. But some of them are rather hard to reproduce because they only occur some times.
@Philipinho Has similar issue with the latest release 0.4.1. The added content disappears or not sync?
And also found the date time is not updated to today on the below screen after adding content in the page
Activity
amamaral commentedon Sep 20, 2024
I don't know if your case is similar to mine, but I've started recently to use docmost and had similar issues when using two accounts. In my case docmost is behind an nginx reverse proxy and websockets were disabled. After enabling websockets the synchronization for multiple users worked nicely.
JohannesFleischer commentedon Sep 24, 2024
@amamaral you are right that the syncing does not work when websockets are disabled. But thats not really a bug but expected bahaviour, because they are used for syncing.
The bug i mention is rather a problem with the usage of the websockets, because false syncing occures in some situations which deletes Data you already created. And this occures even if syncing is correctly configured and works most of the time.
DHS1001 commentedon Oct 10, 2024
I had some situation in the v0.3.0, which is a page is added with some content. But the whole page is disappear the next day.
It might be nice to have a sync status icon on the page.
Philipinho commentedon Oct 10, 2024
@DHS1001 the v0.3.0 bug was fixed in v0.3.1. There are plans for sync status.
DHS1001 commentedon Oct 10, 2024
@Philipinho , that would be great 👍
Philipinho commentedon Oct 13, 2024
Hi @JohannesFleischer, thank you for the candid observations.
In the current design, the page tree currently has limited syncing capabilities because the child nodes are lazy-loaded. With further efforts, this can be improved.
Case 1
In my tests, "file 2" does not get deleted from the database and appears on refresh. Can you confirm this?
JohannesFleischer commentedon Oct 15, 2024
@Philipinho my observations were related to
v0.3.1updating is currently still on my todo list. I can try to reproduce it again in the new version.On
v0.3.1all of these cases occurred exactly like described above multiple times. But some of them are rather hard to reproduce because they only occur some times.DHS1001 commentedon Oct 16, 2024
@Philipinho Has similar issue with the latest release 0.4.1. The added content disappears or not sync?
And also found the date time is not updated to today on the below screen after adding content in the page
[-][BUG]: Syncing inconsistencies[/-][+][BUG]: sidebar page-tree syncing inconsistencies[/+]Philipinho commentedon Oct 29, 2024
@JohannesFleischer I look forward to your feedback on the tree syncing improvements made in v0.5.0
test(editor): extract swap height-reservation into a tested hook (doc…
Merge pull request 'fix(editor): резервировать высоту документа на св…
fix(attachment): don't delete the existing object on a failed OVERWRI…
Merge pull request #39 from cccvu/fix/308-attachment-truncation