Random Duplicate Text Appears everywhere

Lately, I keep encountering randomly duplicated text throughout my notes without any apparent pattern.
I believe this issue is significant and warrants close attention from the product developers.
I have reindexed my graph multiple times, but the problem persists.
Has anyone else observed this behavior?
Attached are some images for reference, and I should note that I’ve edited out any private references.
EDIT: I use logseq Sync and the “smart merge” feature and the latest logseq version.

Image 17-9-23 at 21.57

Today it happened to me too. Do you use Logseq Sync?

yes. I should have mentioned it.
Also I want to clarify that I can’t find a pattern that could explain this behaviour, i.e. I believe it’s not related with an specific tag or reference (even thought in the examples I’ve posted could look like it.

Also I should mention that this issue started to happen a couple of month ago but initially I though it was my fault and deleted any duplicated I found but now I’m sure something is going on.
maybe the experimental “smart merge” ? I’m disabling it for now.

Anyway, to me this is very serious and as I mentioned previously deserves full atention from the developers. I already opened a bug report.
I’m finding duplicated text almost everywhere I look. Here, another example of a jounal page back to July 2021. I have dozen of examples.

FYI I have smart merge enabled too, probably it’s its fault.

I have the same problem when I sync across multiple instances of Logseq. It started happening after I enabled the beta smart merge which I had enabled because some content was disappearing otherwise.

I haven’t investigated deeply but I believe it may be related to having various line endings in your graph. Windows stores EOL as CRLF while Linux stores them as LF only. This means that a line might look the same but be considered different by Logseq based on the line endings.

I am using git version control which is helpful to find those problems and roll the changes back but I believe it may also be the cause of my problems.

1 Like

I was having the same issue. I turned off “smart” merge and it stopped.

Thank you for this discussion folks. I have experienced the same issue and it is clearly associated with synchronization. I will disabled smart merge and see if the problem persists.

Granted this is much better problem than losing data, but I always have to go to each duplicated headline to see which one contains any child nodes. That can be a bit time consuming.

Overall, great product. Very happy to be using this LogSeq

Interesting, to add more information this bug happens to me while using Logseq on Linux and Android only.

Are you using Agenda plugin? I found that moving TODO tasks around or even adding tags would result in duplication. Just a thought.

I occasionally encounter similar issues that are difficult to reproduce, but the one below is definitely reproduced on my device.

I do have the Agenda plugin installed. I have been able to reproduce the bug by opening a TODO item from the Agenda plugin and editing it.

Most of the times I have encountered this issue without using the Agenda plugin and on most occasions it was not even a TODO item. I doubt that the plugin is the root cause but it definitely helps in reproducing the issue and identifying what is going on. Thanks for pointing it out.

@websphere74 - I can see how modifying the same block near-simultaneously on 2 devices (as pointed out in your thread) would create a sync conflict. A better approach could be that Logseq asks for which version to keep but I don’t know if it is on the roadmap.

Sync is broken. I’ve disabled it but still donate because I really want Logseq to succeed. Once was enough for me with some of the data loss issues. Really hoping they get this right…

1 Like

I don’t consider the issue of duplicate blocks being created when the SCHEDULED DATE is modified on multiple devices nearly simultaneously to be a major concern.

However, I do note that it’s an unusual phenomenon that shouldn’t occur if we update using UUID as a key. I wonder if this could provide a clue to resolving other sync conflict issues that inconvenience us.