IndexHandler can get stuck in an undesired loop #9407
Comments
er-pa
added
bug
|
Looking at And indeed on revert we keep that flag when reverting, to avoid sending the index update, see folder_recvenc.go L83+. Now comes the part that explains this observation of yours (emphasis mine):
The revert triggers a scan, and for a real file that exists on a remote, nothing happens on scan. As the revert reset the version, it gets pulled in and everything is up-to-date again. For a locally created file there is no global equivalent. This triggers a special case that removes the file info from the DB (folder.go L607+), and that's where the sequence gets messed up. Stepping back to the beginning:
I think the right solution here is in indexhandler.sendIndexTo, if there was nothing to send, set s.prevSequence to fset.Sequence. Any new change will get a higher sequence, so we can't miss anything - there's no point looking at anything That's easy to do, writing a test-case is likely going to be a bit of work. Hopefully some testcase from @er-pa I won't work on this right now, but will at some point unless you pick it up (very welcome to, you anyway already did the hard work of tracking it down - thanks a lot again!). As in please leave a note here if you do start to work on it. |
Explanation of what/why in a code comment.
Does your log mention database corruption?
No. Completely clean/new instances are also affected.
Version info
The problem
To start with the bad news, the exact trigger isn't very clear as it doesn't always occur using the same sequence. But it happens often enough, and is specific enough, to warrant a separate issue imo.
When debugging and digging into issues related to reverting receive-encrypted folders (I'm not sure if this is solely related to receive-encrypted folders), I stumbled upon odd behaviour. At given times the IndexHandler tends to get stuck in a (seemingly) nothing-to-send loop. To my understanding, this shouldn't really happen as eventually some wait-conditions should be triggered. The problem, when this happens, is that the affected Syncthing instance seems a bit ... unreliable.
Steps to reproduce:
receive encryptedObservations
I enabled DB-logging and I added a custom log-line in the IndexHandler (in the
for err=nil-loop) to see what sequences are involved. Apart from that added log-line, the main-branch was used (so no additional changes were involved).The following will be repeated endlessly, around 4 times per second.
This was traced back to the function
(s *indexHandler) sendIndexTo.Since there are some mechanics involved to wait for the sequences to be updated (to my understanding), the added log line kept track of those;
1 - Base: fstat.Sequence: 25, s.prevSequence: 25
2/3 - After creating local file: fstat.S: 26, s.prevSequence: 26
4 - After reverting: fstat.Sequence: 27, s.prevSequence: 27
so far so good...
7 - After pausing-unpausing: fstat.Sequence: 27, s.prevSequence: 25
Since the prevSequence is now 25 for some reason (obtained from the sending node?), it calls
withHaveSequencewith 25+1 and that doesn't result in anything and then nothing really happens in the remaining parts of the functions other than just repeating it.Logs
(filtered out unrelated verbose items, if it's too filtered I can always reproduce it again..:))
The text was updated successfully, but these errors were encountered: