IT HAPPENED AGAIN. I was typing some new stuff, realized i had no internet connection, so I fixed that. Lost about 4 lines of text as the sync kicked in and deleted the stuff I just created.
DOES nobody else have this issue? For anybody trying to do multi-user editing I canât believe it doesnât come up more frequently.
Itâs not a common occurrence for me because I am aware of the bug and try to avoid it, but it does happen, and this is still my A1 priority.
I thought of a simple solution, unless Iâm wrong:
Make the Sync operation always operate as
- local edits sent to server and merged.
- server data sent to client.
Now with 1, you need to ensure every edit or add arrives at the server. If a parent node was erased, it needs to be brought back to service the current edit. Take the version from the client.
The value of this process is you have the version history on the server, so if anything of the result is undesired, you can go to the history to recover it.
As things are currently, local edits can be erased by the sync process and no history exists.
I just realised that I lost important notes by accidentally editing and syncing a document from my phone BEFORE retrieving the edits on the same document from my laptop.
@Masato_Kakinoki, is it possible your notes are still in the version history? Even if they got overwritten with the server version, they might be visible as a previous version of the doc.
Craig, you understand the problem in the word âmightâ? It depends on which order it happens, and if the order is wrong, the data is just erased with no recourse.
Yesterday I upgraded my account to PRO just to retrieve the lost notes, but they were not there. I hope support team can retrieve them. I wish Dynalist had an Evernote-like solution (Evernote keeps conflicts as âConflicting modificationâ). Now I am considering switching back to WorkFlowyâŚ
Which service are you using now to avoid this risk? WorkFlowy?
Aw, bummer. So sorry to hear that. 
I hope the Dynalist team can help you out.
Thank you Craig.
This, or something just like it, just happened to me. Yesterday I was in a location with poor service and today when the sync occurred I could see an item I entered yesterday was visible and then disappeared. What makes me wonder if this is slightly different is that then a dialogue appeared saying I didnât have a document selected and that I needed to choose one in the documents list. After choosing the same document I previously had active (I mainly work on only one) the entry I made yesterday was definitely gone.
I ran into 2 data loss issues with Dynalist so far. Once where a node was missing on mobile, then when I looked on web, it was also gone there. Once where a note on an item went missing.
I love dynalist as a product and was considering moving more stuff over to it but data loss is very scary.
This is still an issue. Syncing regularly deletes data for me. Please fix it if you can.
I agree itâs an issue. Since then I have learned a meticulous way of working to be sure this never comes up. I always ensure documents are synced before I delete anything. Itâs the only way.
I have no issues. But I am super curious about folks who do. There must be some common denominator?
Iâve used dynalist daily for 4+ years now and never had data loss. I use the mac app and the browser website, and the API thru various scripts, and android apps.
Theories:
As I vaguely understand it, each bullet point has a unique ID number and last modified date. So for a sync issue to occur you must:
Iâm kind of foggy of what exactly is happening to folk - items are disappearing? Are you sure you didnât just move or delete it on another device, and youâre witnessing that sync? Or it just got pushed off the page by everything else that synced? Anyone have guesses whatâs going on technically, with the folks having issues?
The prerequisite to getting stuff to disappear is probably inconstant internet connection. If you make an edit in two devices and then sync, thatâs when it can go wrong. And specifically if the operation in one of these places is to delete something.
The reason this comes up is probably because there isnât necessarily a constant relation between the content of a node and the node itself. You can press enter to split a node or create a blank node, you can cut / paste stuff, and on another device that wasnât synced, you might delete what looks like an irrelevant line, but on the other end it had become relevant content. But at sync that relevant content is deleted.
I think the ideal solution would be a recycle bin document where anything that gets deleted gets sent to that bin where you could visit and Move back in. This must include content that gets sent to the server after the contentâs node is deleted. Currently Dynalist discards such because thereâs nowhere to put it.
By the way, even though Iâm a die-hard DynaLister, this issue is why I do not and have not recommended everybody at my work team get the tool to share notes. Itâs just too dangerous. As a solo worker I can avoid these bugs. If this were resolved Iâd change my tune.
Just curious, have you checked the Version History option in Dynalist?
Most likely all the changes and the deleted stuff are somehow still registered in there, as red and green.
Itâs just a matter of reviewing this piece of feature from time to time, whenever we âfeelâ the normal sync was not that reliable.
Yes, on occasion. In fact, Version History has most changes, but sometimes if sync doesnât do itâs thing somethings are lost. It hasnât been an issue for a while since Iâve learned to avoid the bug.
Iâve got the nub of the issue. Iâm sure the Devs can confirm this if they try: if two devices change each a node and then sync, do both edits go to the server?
The answer ought to be yes but is actually no, at least for certain kinds of changes The later edit ought to become the current text, and the earlier edit is in the history.
I think in the case of simple text changes this may work right, but iâm not certain. In the case where the first to sync deletes a line, the second to sync gets its change rejected because the node is no longer in the document. It would be better to restore the node so the edits can be put into the server. Then we could use History to reconcile the issue because all changes are on the server.
A bad behavior would be if sync first retrieves edits from the server, and local edits get clobbered never having been put into the database.
Two changes does both get to the server, but indeed if one session deleted an item, then the second one will not make it. I will think more about it and see if thereâs some way to restore it.
Itâs bit me again. I had been pretty good at avoiding this bug but this past week Iâd been pushing DynaList to the max and boom: a whole lot of stuff vanished. Specifically, Iâve been restructuring my knowledge base, and getting into a workflow like Obsidian enables: side by side document panes. DynaList can do this with the web version (and the other side may be the app version, or another browser window). So somewhere in the midst of cleaning up things, I deleted stuff in one window, and in the other window same document I was writing different things. And that got deleted. Not a big deal, because I know what I wrote and could write it again.
But this is the one issue that prevents me from telling everybody to get DynaList. Although if most people only use one window one device it would never come up. But for me, the multiple device thing is absolutely the first reason I use DynaList. Who else has quality Windows, iOS, and Web experience and syncing?
[ And also fast outlines, and quick keyboard manipulations, and bountiful styling, and ⌠]
But all that is moot if your data gets lost.
In light of this, and in light of all the requests for finding lost data caused by other accidental deletions, can you PLEASE add a magic file that holds all the things you delete (or additions/edits that the server fails to accept because the target node is gone). It acts as a trash bin / recycle bin. (OneNote has this as a Deleted Notes section; it also generates conflict pages if sync isnât smooth.)