Fedora42 KDE desktop syncing issues with the app

[carloshelly]

Description

Everything is going well from the server sync to any browser access to my nginx setup running at notes.mydomain.ca
I have been quite successful with this for months until 0.94.x version came out. Everytime I open my app (not the browser), it will create an insane amount of spam 24/7 in the server logs.

I've tried to disable the AI feature because im running several ollama AI in many unraid setup for fun. I also tried to redo the embedding, etc. Nothing works. Triliumnext app (flatpak or .zip or .rpm) will just create this insane loop described below. What you are seeing is when I tried to uncheck the LLM feature.

Also, the sync icon the app is turning none stop probably due to that code loop.

Is there a way to rollback everything to 0.93? I tried, im getting database error messages when trying.
My other solution would probably be to export all of it and destroy this docker.

Thoughts? Thanks!!

TriliumNext Version

0.94.1

What operating system are you using?

Other Linux

What is your setup?

Local + server sync

Operating System Version

unraid docker-compose file for the server + app on the machines

Error logs

200 GET /api/sync/changed?instanceId=31qijao1Jrnm&lastEntityChangeId=122365&logMarkerId=15wIYoT7xf with 83960 bytes took 4ms
200 GET /api/sync/changed?instanceId=31qijao1Jrnm&lastEntityChangeId=122411&logMarkerId=qvrkSb0JsL with 73 bytes took 3ms
204 POST /api/sync/finished with 0 bytes took 1ms
Content hash computation took 12ms
Slow 200 GET /api/sync/check with 14680 bytes took 15ms
204 POST /api/sync/check-entity-changes with 0 bytes took 8ms
Added sector 6 of 'note_embeddings' (11 entities) to the sync queue.
204 POST /api/sync/queue-sector/note_embeddings/6 with 0 bytes took 5ms
Added sector 9 of 'note_embeddings' (13 entities) to the sync queue.
204 POST /api/sync/queue-sector/note_embeddings/9 with 0 bytes took 5ms
Added sector G of 'note_embeddings' (14 entities) to the sync queue.
204 POST /api/sync/queue-sector/note_embeddings/G with 0 bytes took 5ms
Added sector v of 'note_embeddings' (9 entities) to the sync queue.
204 POST /api/sync/queue-sector/note_embeddings/v with 0 bytes took 4ms
304 GET /api/setup/status with 59 bytes took 0ms
200 POST /api/login/sync with 56 bytes took 2ms
Sending message to all clients: {"type":"sync-pull-in-progress","lastSyncedPush":0}
updated: {}, alreadyUpdated: 0, erased: 0, alreadyErased: 0
204 PUT /api/sync/update?logMarkerId=Ru1S04x4fh with 0 bytes took 7ms
Returning 23 entity changes in 2ms
200 GET /api/sync/changed?instanceId=31qijao1Jrnm&lastEntityChangeId=122434&logMarkerId=GYdg5L9yKB with 83960 bytes took 4ms
200 GET /api/sync/changed?instanceId=31qijao1Jrnm&lastEntityChangeId=122480&logMarkerId=nBHbzaY7k6 with 73 bytes took 1ms

(in a loop every 50ms maybe, its spamming none stop)

[betrion]

I experience the same issue, both server and linux app on 0.94.1. Just a constant loop trying to sync app to server:
trilium-1 | 200 GET /api/sync/changed?instanceId=Bw8PP807rUBa&lastEntityChangeId=7009772&logMarkerId=23GapPTkEA with 1604 bytes took 2ms trilium-1 | 200 GET /api/sync/changed?instanceId=Bw8PP807rUBa&lastEntityChangeId=7009922&logMarkerId=oqcvdeoqXJ with 74 bytes took 2ms trilium-1 | 204 POST /api/sync/finished with 0 bytes took 1ms trilium-1 | Content hash computation took 27ms trilium-1 | Slow 200 GET /api/sync/check with 15976 bytes took 31ms trilium-1 | Slow 204 POST /api/sync/check-entity-changes with 0 bytes took 12ms trilium-1 | Added sector 5 of 'note_embeddings' (27 entities) to the sync queue. trilium-1 | Slow 204 POST /api/sync/queue-sector/note_embeddings/5 with 0 bytes took 10ms trilium-1 | Added sector D of 'note_embeddings' (35 entities) to the sync queue. trilium-1 | 204 POST /api/sync/queue-sector/note_embeddings/D with 0 bytes took 7ms trilium-1 | Added sector G of 'note_embeddings' (28 entities) to the sync queue. trilium-1 | 204 POST /api/sync/queue-sector/note_embeddings/G with 0 bytes took 6ms trilium-1 | Added sector I of 'note_embeddings' (30 entities) to the sync queue. trilium-1 | 204 POST /api/sync/queue-sector/note_embeddings/I with 0 bytes took 6ms trilium-1 | Added sector J of 'note_embeddings' (31 entities) to the sync queue. trilium-1 | 204 POST /api/sync/queue-sector/note_embeddings/J with 0 bytes took 6ms trilium-1 | 304 GET /api/setup/status with 59 bytes took 1ms trilium-1 | 200 POST /api/login/sync with 57 bytes took 1ms trilium-1 | Sending message to all clients: {"type":"sync-pull-in-progress","lastSyncedPush":0} trilium-1 | updated: {}, alreadyUpdated: 0, erased: 0, alreadyErased: 0 trilium-1 | Slow 204 PUT /api/sync/update?logMarkerId=BrwTEY8AzO with 0 bytes took 19ms trilium-1 | Returning 5 entity changes in 1ms trilium-1 | 200 GET /api/sync/changed?instanceId=Bw8PP807rUBa&lastEntityChangeId=7010069&logMarkerId=1BlediG4y8 with 1604 bytes took 2ms trilium-1 | 200 GET /api/sync/changed?instanceId=Bw8PP807rUBa&lastEntityChangeId=7010219&logMarkerId=6O7gAOkyaQ with 74 bytes took 2ms trilium-1 | 204 POST /api/sync/finished with 0 bytes took 1ms trilium-1 | Content hash computation took 22ms trilium-1 | Slow 200 GET /api/sync/check with 15976 bytes took 26ms

[eliandoran]

If you made use of LLM, it's a sync issue with it.
I believe we've solved the issue but it's not yet released. Be on the standby for this weekend.
Technically speaking it should not affect your sync too much, apart from useless CPU/network consumption.