Desktop app sync activity removes notes that didn't exist last time app was opened

[inrush-overload]

Description

It seems that there is an improper sync activity that doesn't appropriately check for recency of databases and simply pushes the desktop app's database to the server, resulting in new notes being deleted.

Reproduce:

have a synced version of desktop app, synced to a server

close desktop app. Use different PC/browser/etc to edit notes in web ui and create new notes, and allow to sync

open desktop app, wait for sync, find newly created notes are now disappeared and must be recovered

TriliumNext Version

0.0101.3

What operating system are you using?

Ubuntu

What is your setup?

Local + server sync

Operating System Version

Ubuntu 25.10

Error logs

NO error logs found, it appears the app thinks this is normal behavior.

[dosubot]

Hi @inrush-overload! I'm Dosu and I’m helping the Trilium team.

This is a known issue in Trilium's sync system. Sync conflicts are resolved using a last-write-wins approach based on timestamps, so if the desktop app is offline while new notes are created and synced from another device, reopening the desktop app and syncing can overwrite or delete those newer notes if its local state is considered "newer" by timestamp. There is no special logic to detect or warn about these conflicts, and no error logs are generated—Trilium treats this as normal behavior source.

To reduce the risk of losing changes, manually trigger sync on all devices before editing after resuming a suspended client, and make sure device clocks are synchronized. If notes are lost, you can usually recover them from the note's revision history source. There are no recent fixes for this in the codebase, and the sync logic still relies on timestamps without explicit conflict resolution or user warnings source.

If you encounter orphaned or misplaced notes, try restoring from internal backups, using the Note Revisions dialog, or using "force full sync" and "fix consistency issues" features source.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[hulmgulm]

I tried to reproduce your issue:

• I closed my desktop client
• opened Trilium in my browser and added a new note
• I opened my desktop client again
  => the newly created note gets synced to the client as expected, not deleted.

[hulmgulm]

Another try:

• I shutdown my Trilium server
• created a new page on desktop client
• closed my desktop client
• started Trilium server, the page created on the desktop client is not visible, as it did not get synced
• created a new page on the server
• opened the desktop client
  => after the sync, the page created on the desktop client was visible on the server and the page created on the server was visible on the client, as expected.

[eliandoran]

@hulmgulm , thanks for testing.

@inrush-overload , I suspect the issue you are encountering might be related to the environment than everything else.
The only known issues with sync in Trilium is if you edit the same note twice in two offline instances and then syncing, case in which the latest one always wins.

Disappearing notes is unlikely given the scenario. Can you specify more how the desktop and server is set up?

Important:

1. The server must not have its database stored on a network drive (e.g. NFS, SMB).
2. The Trilium database must not be altered externally, either on the desktop or the server.

For information, the database is not actually copied over on sync. Each time a modification is made, a record of that modification is stored separately (called entity changes), and those modifications are actually synced. The database is never transferred directly, not even during the first setup.

[inrush-overload]

Hi @hulmgulm and @eliandoran - Regarding the important notes left - I have the server configured in a Docker instance with the database stored on a local storage drive for the VM.

The trilium database has no external modifications being made.

further context/details:

A note I'd written 2-3 days ago was modified, a sub-note was created with some of the contents of that and successfully stored (and externally shared, even) in trilium using the desktop application on a laptop that is set up to sync to my server on Docker. We'll call this "Profile A"

The newly created subnote was then modified and edited in the web browser of a desktop system at some point between then. Only contents, no structure/tree changes.

I opened Trilium on a different laptop user account (I have a focus account for writing, but wanted to check something)- We can call this "Profile B". This is the profile I had been working on the parent note in originally. When the application opened it had an extended "Sync" period.. When it completed, it appeared that no updates had happened and the child note was not present.

I checked on the web browser on the same laptop and found the sub-note that had been created/edited was no longer present on the server via the web interface, BUT when I opened Trilium on the desktop instance I had been recently editing in, the note opened in the UI but was marked as "Recovered" and removed from its nested position in the tree and placed to the bottom of the notes tree. I could not remove the "Recovered" pretext so duplicated the note and returned it to its location where it shows with the correct title now.

[eliandoran]

@inrush-overload , correct me if I'm wrong, but from what I understand there was no data loss, right? Only structure loss.
Trilium checks the integrity of the database at every startup (either desktop or server).

Say you have the following structure:

myFolder
 -> noteA
 -> noteB

If you create myFolder/noteC and then, on an offline client (due to WI-Fi off, VPN disconnected, etc.) you move noteA and noteB in another parent and delete myFolder, noteC that was created somewhere else has nowhere to go. When the sync is finally done, noteC will end up as recovered.

The content of a recovered note is not affected, only where it's placed.

Regarding the prefix, you can simply edit the branch prefix by pressing F2 on the note in the note tree.

[inrush-overload]

By the sheer miracle of the note still being "open" on the desktop system the note was not lost. The database tried to lose it but somehow it "recovered" when the desktop instance asked for a note that the server thought was gone

@inrush-overload , correct me if I'm wrong, but from what I understand there was no data loss, right? Only structure loss. Trilium checks the integrity of the database at every startup (either desktop or server).

Say you have the following structure:

myFolder
 -> noteA
 -> noteB

If you create myFolder/noteC and then, on an offline client (due to WI-Fi off, VPN disconnected, etc.) you move noteA and noteB in another parent and delete myFolder, noteC that was created somewhere else has nowhere to go. When the sync is finally done, noteC will end up as recovered.

The content of a recovered note is not affected, only where it's placed.

Regarding the prefix, you can simply edit the branch prefix by pressing F2 on the note in the note tree.

[inrush-overload]

Looking at this further it appears the Desktop app is attempting to sync at boot and failing (wrongfully) thinking it is offline or unable somehow to reach the server (I am able to reach the server in browser however).

Speculation: If there is conflicts in the database when manual sync is attempted it is pushing the local database to the server and for some reason the server is accepting this as the 'current' database for some reason.

What I've just tried/observed:
The spinny-icon is continuing in the desktop app indefinitely, after launch - indicating trouble synchronizing/unknown status.

When navigating in desktop app to settings > sync > test, it confirms the handshake was successful but the sync icon continues spinning. no syncs are coming down from server-side changes and the local change sin the app are not going to the server from the desktop app.

Attempt to manually sync from the app is not successful either within reasonable timelines. (Icon continues to spin...)

Approximately 15 minutes after opening the app (I wasn't timing it...) the sync in the local app was successful. It updated, the icon stopped spinning and appeared as the "Wifi" sync icon - It lost the local edits and updated with the server-side edits which is the expected/desired behavior for sure, but the extreme amount of time to establish synchronization is worrying.

At this point however the sync is effectively realtime and as expected, and we are not losing information. I think there is an issue with the establishment of sync in my setup that might be causing collisions and potential for loss of data.

[eliandoran]

@inrush-overload , can you provide the backend and frontend logs? Perhaps we can notice why the sync is having trouble working in your particular case.

By the sheer miracle of the note still being "open" on the desktop system the note was not lost. The database tried to lose it but somehow it "recovered" when the desktop instance asked for a note that the server thought was gone

This is not exactly what happened. The application/database is not trying to remove anything, it just happened that there was a conflict between the two imports.

Data loss in Trilium doesn't occur as notes that are disappeared, only structure losses (the notes are moved to the root with the recovered prefix) or if the same note is modified by two offline instances, only the most recent version is kept.

As soon as we determine why the sync is not working for you, you should no longer have this kind of issues.