Data loss upon opening logseq: externally added content to today's journal about logseq

[deviant]

I am running into this also. I'm using Syncthing to access my Logseq graph across multiple computers, which is the main place where I experience this issue, but occasionally get tripped up when editing pages in a text editor as well. I'm currently working around this by obsessively exiting editing mode every time I switch away from Logseq, leave a computer, lock my phone, switch between devices, etc. While this works, this is obviously annoying and unpleasant to do, and there's still a risk if I forget (for whatever reason).

The bug does actually affect all pages, not just the journal— it's just much easier to trigger via the journal. Part of this is because Logseq enters editing mode when opening new pages, which happens automatically for each new day while viewing the journal. Also, since it only occurs when the currently edited line changes, it's more likely to happen when you keep a blank line at the end of the page, ready for input (as I do)— this makes sense to do in the journal, but less-so in regular pages.

It's also not quite accurate to say that the data is "lost", although it is without intervention. The line currently being edited can be restored by using the Undo command. It seems to me as though Logseq implements reloading of files by reading in their contents, positioning the cursor on the line it was previously at, and then overwriting the line with the previous contents of that line prior to the reload.

This behaviour definitely seems suboptimal. Instead I think Logseq should be diffing the two versions of the file to find the new location of the currently edited line and its surrounding context, and reposition the cursor there instead. If it can't find either of these, it should just fall back to creating a new line at the end of the file. If it can, and the currently edited line has only changed partially, it's probably sensible to just use the version from the file, rather than duplicating it. (I'm unsure whether it's better to keep the cursor at the same column, or move it to the end of the line, but plausibly the latter). If there is common context, but the currently edited line is not present, and there are new lines in the file where it's supposed to be, it should probably be moved after the last of these new lines— but only after ones that are at or below its current indent level, to preserve semantics as best as possible.

I hope the description of this logic isn't too difficult to understand! There are quite a few points that need to be given consideration in order to have a (relatively) seamless experience here.

As an aside, the snapshots in logseq/bak offer another way to retrieve the missing data, if you're not too slow about it, but it might not be in there if you're unlucky.

While debugging this, I also managed to run into a bug where the backing file and its state in Logseq could become permanently diverged (not fixable with a regular graph refresh, requiring a full re-index to remedy). I'm not sure what the exact steps were, but it involved going back and forth between editing a page in Logseq and a text editor, and Undo/Redo in Logseq. Possibly a race condition. After this was triggered, edits to the backing file would no longer end up in Logseq, and Logseq stopped saving its state to disk. This persisted through restarts. Unsure if this is relevant to the current issue, but figured I'd include it just in case.

[MarSik]

I am seeing the same behavior. My second computer lost the first entry from each day this way.

[e-zz]

This is common when you have two different devices running Logseq all the day.
Logseq automatically jumps to the next day's jornal page when the day changes, and enter editing mode in the first block. So if you have one remote device also running Logseq, basically it means you have a remote client always editing the first block. That's why it happens.

One workaround is to close Logseq on your machine when you leave it. Another is when you come back to the remote machine, which is editing the first block, press Esc to exit editing mode without editing. Then it should be fine.

But I still hope Logseq devs can provide a way to turn it off. This behavior is indeed sometimes annoying.