2024-07-06a - Conflict Note 770b17165d8f453890ae49066bcc928e from 23.8.2022, 13:17:29
Forked from
Late this afternoon, I chose a first problem for closer examination.
It's a small note about a nice restaurant that I noticed while on vacation 8/23/2022, 13:17:29.
This note contains the URL of the place and two screenshots - probably the logo from the website and maybe from the menu.
I'm pretty sure I haven't changed the content of this note since then - also because the user_updated_time is unchanged 8/23/2022, 13:19:15.
What I did do, however, is that I moved this note to a different folder after my migration to Joplin Cloud Teams. This folder is a subfolder that is two levels below a folder that I share with another Joplin user in Joplin Cloud.
In the conflicts folder of Windows and Android there are 12 conflicts each with this ID as conflict_original_id with other own IDs. Neither the two notes 770b17165d8f453890ae49066bcc928e nor the corresponding notes in the conflicts folder show the original screenshots - everywhere only the "still needs to be downloaded" symbol with the arrow pointing downwards. The search for the IDs of the screenshots from the MarkUp of the note using the note info plugin results in type_ = null.
I can find this note with the same ID 770b17165d8f453890ae49066bcc928e in both the Windows app and the Android app. Unchanged are the same old timestamps of created_time, user_created_time and user_updated_time, which are identical in both Windows and Android.
What I don't understand, however, is why the content of updated_time seems to change so often. Today around 16:57 ( Windows ) and 17:50 ( Android ) the timestamp there was 6.7.2024, 14:21:49 . Today around 21:58 this timestamp was for both Windows and Android on 1720294749056 - 6.7.2024, 21:39:09.
I only looked at this note and did not (knowingly) change it - neither in Windows and certainly not in Android.
How can this change to the content of updated_time be explained if I have not (knowingly) changed this note?
Thank you for splitting this up into a separate topic!
This response provides two things to try and a list of notes for myself as I continue to look into this.
Things to try
Here are a few things to try:
If it's still enabled, try disabling OCR. (Goal: Limit external resource modifications).
On desktop, check to see what revisions exist for the note. (Goal: Determine whether the problematic note updates are being stored as revisions.).
To do this:
Open the problematic note.
Click "note properties":
Click "previous versions of this note".
Click on items in the dropdown to view previous versions of the note:
Questions: How many revisions are there? If there are many, what are the changes between them? (Are the item ID changes showing up in the revision history?)
Additional notes
I'm leaving a few notes to myself and anyone else looking into this:
Note conflicts are created in Synchronizer.ts in at least two cases:
As a result, one possibility is incorrect system time on the Windows or Android computer. However, this should not cause resource IDs in the body of a note to change.
Possible next steps:
Compare the updated_time with the timestamps in Joplin's log — from this, it might be possible to determine what's happening when the note is updated (e.g. is it during a sync? During OCR? While viewing the note in the Rich Text Editor?)
Update the debug info plugin to allow keeping a temporary log of recent note updates using the ItemChange event (this would likely be a setting).
The ItemChange event might not be fired for these note updates.
If it is fired for these note updates, it could make sense to only log note updates where a large number of resource link IDs were changed. If this is done it would give the following information: How often are item IDs being replaced? What timestamps are these IDs being replaced at? By comparing the replacement timestamp with Joplin's existing logs, it might be possible to determine the source of the change.
For additional context, the info plugin could also log: 1) Whether a sync is ongoing, 2) whether the note is shared.
Check whether debug logging provides enough information to determine the source of a note modification. If not, create a custom build of Joplin with more logging enabled?
type_=null means that the item with the specified ID doesn't exist on the current client.
770b17165d8f453890ae49066bcc928e
shows a dropdown menu with 200 previous versions
(+0) ........... most versions
(+200) ....... 5 versions - incl. the eldest entry in the versions dropdown
(-64, +64) .. 3 versions
The eldest version with
(-64, +64)
11/06-2024 - 19:31
looks perfect.
All 16 newer versions above this version with
(+0)
look perfect as well
The second eldest version with
(-64, +64)
12/06-2024 - 02:20
looks bad again.
All newer version look bad.
In this mode, I can't see how to view the MarkUp without overwriting the faulty note with a good old version. Is there a way to do this? Or can I safely overwrite the defective current version with the oldest good version without destroying traces that could still be of interest to us in this analysis?
My question was wrong because it was based on a false assumption.
I picked out a second problem case and worked relatively courageously with the dropdown to view previous versions and restored a version.
I was surprised and pleased that this action did not result in my original note being overwritten:
Restoring a version from the drop-down menu has created a new note with a new ID in the previously non-existent "Restored Notes" folder.
previous versions