Yesterday I was taking notes on my laptop (linux). Everything synchronized and I closed the app with no trouble. Later during the same class, I had to add some diagrams to the notes. I opened the same note on my surface pro 4. I continued taking notes.
Now on my surface pro, I keep receiving errors as seen in the following screenshot:
The console shows the following:
C:\Users\auroq\AppData\Local\inkdrop\app-3.22.0\resources\app.asar\node_modules\debug\src\debug.js:115 Save error: Error: Document update conflict
at metaToPlainObject (C:\Users\auroq\AppData\Local\inkdrop\app-3.22.0\resources\electron.asar\renderer\api\remote.js:288)
at metaToValue (C:\Users\auroq\AppData\Local\inkdrop\app-3.22.0\resources\electron.asar\renderer\api\remote.js:230)
at metaToValue (C:\Users\auroq\AppData\Local\inkdrop\app-3.22.0\resources\electron.asar\renderer\api\remote.js:222)
at EventEmitter. (C:\Users\auroq\AppData\Local\inkdrop\app-3.22.0\resources\electron.asar\renderer\api\remote.js:299)
at emitThree (events.js:116)
at EventEmitter.emit (events.js:197)
Every time, I also get a new note next to my existing one title the same but with “[conflicted]” in front.
I see the same thing across every note I take now on both my surface and my laptop.
- Platforms: Windows 10, Arch Linux
- App Version: 3.22.0 (on both machines)
This is reproducible every time I create notes now.
Thank you for reporting it.
I suspect that the note is being saved twice at the same time so conflicts are happening but I don’t get why this occurs.
Could you try following steps?
- Stop all Inkdrop process on your all devices & machines
- Start one process on your surface pro
- Wait until sync completed
- Edit a note
Ctrl-S to save the note
- Check if a conflict occurs
I followed your steps, and had no issues; however, as I continued taking notes today, I ran into a couple more conflicts. It seems that it is occurring as I
habitually obsessively use Ctrl-S to save the note. I have a compulsive habit of hitting Ctrl-s after typing anything when using any word processor or similar application.
That being said, it does seem to be intermittent. I will try to work with the Dev Tools open and post here if I find any new info or a different stack trace.
I think I got it.
Inkdrop manages your notes with revisions.
It needs the last revision to write a new version.
When saving a new version but the current revision is not latest, the app thinks there is a conflict, because other instance has made a new one.
It might happen when you try to save editing note too frequently because I/O doesn’t finish.
That is, two writing operations happen almost at the same time. So the problem occurs.
Seems like you edit notes so fast. The app can’t catch up your speed.
So it’d be good to ignore save commands while the app is currently in operation to save a new revision.
I wondered if it was something like that. It’s just odd that I haven’t seen it until this version. I guess it’s time to break my compulsive saving habit and start trusting modern autosave features.
Yeah, that would be definitely nice.
I have the same problem with conflicted notes. I operate my own sync server that might be slow to respond at times.
If it’s a problem with I/O maybe sync requests should be queued?
How often does it occur?
Sync and remote I/O are both nothing to do with this problem because the app first tries to write data to the local database.
There is some kind of conflict now every time I open Inkdrop and start editing notes. So far I just deleted the conflicted notes as they seem to represented an earlier revision (before saving), sometimes the content is identical though. I get the same message as OP before the failure occurs on the first conflicted note.
Just to be sure I just did the following test. I closed and reopened Inkdrop, clicked “Synchronize notes”, searched some old note that I last saved before the conflicts first started, edited it and it also ended up being conflicted. So something is not right at the moment with the way revisions are handled. The problem started with the latest version of Inkdrop.
I forgot to mention that I could not properly install the latest update on Fedora. The GNOME package installer just stopped and I didn’t want to bother, so I just deleted parts of the local cache files until it would succeed. Maybe the note conflicts are somehow the consequence of that?
Thank you for reporting. I’m still struggling to reproduce this problem.
As you guess, I think something is not right at the moment with the way revisions are handled. My hypothesis is that another save action is unexpectedly called by certain event handler and that causes the saving operation runs twice at the same time. I heard that some other people are also getting this problem and they can’t describe how to reproduce it. So it seems like probabilistic.
As I mentioned earlier, it’d be good to ignore save commands while the app is currently in operation to save a new revision.
And I built a patched version for Fedora here, could you try it?
The patched version does not produce conflicts. There is a caveat though. Sometimes notes are not saved even though I explicitly press CTRL+S, then my changes are gone. Other times saves are delayed and occasionally everything works just fine. It’s a mixed bag.
To clarify the changes are gone once I leave the note.
Got it. This problem must be caused by disk I/O delay and the app should have a queue for save ops.
Thank you again for your report!
I will give it a shot tomorrow. Thanks for the quick bugfix.
Conflicts are back and all the side effects from the first patch still occur. Actually now I get conflicted notes all the time. At least it’s consistent in that manner. Hope you can narrow it down further.
Just recorded a demo where I created a new notebook and added some notes to demonstrate the conflicts, but much to my surprise everything worked fine. So conflicts only occur with “old” notes .
Thank you for trying the patch.
That’s weird…so you get conflicts only with all old notes, not particular notes? hmm…
Could you send me a debug log? You can enable debug log like so in console:
var debug = require('debug')
You might have a different problem from Parker’s and maybe it’s potentially a PouchDB bug.
I guess removing your local db and performing a full-sync would solve the problem.
I did a full-sync and running the patch-2 version I haven’t had any issues with conflicted notes as of now. Seems you are right in that I was experiencing PouchDB problems. I will report back in case there are any more conflicts.
Good to hear that.
However I tried to repeat changing and saving a note 160 times but no conflicts happened.
Saving always finished immediately so I don’t know why it takes for a long time.
I suspect that the workaround won’t work for other people.
I need more information to narrow it down further.
Please send me debug logs
Anyone, please send me debug logs when you get unexpected conflict error.
You can enable debug log like so in console:
var debug = require('debug')
If you mind to share your log here, please DM me your log, or you can mask the note body and title part.
I guess that db compaction solves it as well.
conflict: Document update conflict
at metaToPlainObject (/Applications/Inkdrop.app/Contents/Resources/electron.asar/renderer/api/remote.js:288:5)
at metaToValue (/Applications/Inkdrop.app/Contents/Resources/electron.asar/renderer/api/remote.js:230:14)
at metaToValue (/Applications/Inkdrop.app/Contents/Resources/electron.asar/renderer/api/remote.js:222:22)
at EventEmitter.<anonymous> (/Applications/Inkdrop.app/Contents/Resources/electron.asar/renderer/api/remote.js:299:31)
at emitThree (events.js:116:13)
at EventEmitter.emit (events.js:197:7)
◆conflict notes （現在conflict中）