Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

lib/model, gui: properly handle reverting receive-encrypted folders (fixes #8196) #9319

Draft
wants to merge 5 commits into
base: main
Choose a base branch
from
Draft

lib/model, gui: properly handle reverting receive-encrypted folders (fixes #8196) #9319

wants to merge 5 commits into from

Conversation

er-pa
Copy link
Member

@er-pa er-pa commented Jan 3, 2024

Purpose

Take deleted items into account when checking for changed receive-only items in receive-encrypted folders, as these don't trigger an index update. Cleaning up unexpected folders didn't trigger a local-state change at all, so this was adjusted as well.

In addition, specific headers and messages/labels existed in the GUI for the event of unexpected items in receive-encrypted folders specifically, but these were never triggered. A minor tweak was added to handle this (again, I guess).

Testing

  • Create some receive-encrypted folder.
  • Optionally (for completeness) sync some items
  • On the receiving end, add some files or folders
  • Press the fancy red button in the gui
  • That button (and the 'Unexpected items' state) no longer gets stuck while the reverting was properly performed.

@er-pa
gui: properly handle reverting receive-encrypted folders (fixes synct…
d81c164 
…hing#8196)

Take into account locally deleted items when checking for locally changed receive only items. In addition, specific headers and messages/labels existed for the occurence of unexpected items in receive-encrypted folders but these were never triggered. That was taken care of as well.
@er-pa
add improved folder support
6bf0ba5
@er-pa
proper local flag
3f99d97
@er-pa
wip
8995265
@er-pa
style
e6779fa
imsodin
imsodin reviewed Jan 3, 2024
View reviewed changes
lib/model/folder_recvenc.go
if iterErr = batch.FlushIfFull(); iterErr != nil {
return false
}
_ = batch.FlushIfFull()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we ignoring these errors?

lib/model/folder_recvenc.go
ModifiedBy: f.shortID,
Deleted: true,
Version: protocol.Vector{},
LocalFlags: protocol.FlagLocalReceiveOnly,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this the opposite of what we want? As we still have a receive-only entry in the db, while we want to get rid of them.

The intention here (not saying it works, clearly it at least partially doesn't) is that we remove the locally changed directly and trigger a scan. The scan picks up the deletions, and as the global is also deleted marks it as not a locally changed item in the db (normal scan behaviour to not produce spurious locally changed items). I guess that's not what's happening in reality? Could you explain what is please.

Copy link
Member Author

@er-pa er-pa Jan 28, 2024 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did some digging. And you're right, my approach wasn't right simply put. What I observed, but I think I stumbled upon another issue which may or may not be related but made it slightly annoying an inconsistent, is that three things are involved:

1.) It does remain a 'locally deleted item' unless I manually trigger a scan of the folder afterwards, done via the API (as the watcher is I think per default disabled and the rescan interval an hour). Note, that after this point the state only becomes correct in new clients. Any open client remains faulty, which leads to the following point (related, as this would be required, I think, from how it should work).
2.) The verbose FolderSummary event does not send out a recalculated version, potentially because this only seems to occur immediately when either something restarts or the folder state becomes idle from either syncing or sync-prepping. In this revert-case it all gets cleaned up by a simple scan, so it just waits till the scheduled recalculation which I'm not sure of when this happens.
3.) The IndexHandler often gets stuck, this tends to make the whole instance unreliable/unstable. Sadly a very stable reproduction isn't possible, but it tends to happen quite often when fiddling with reverts in a receive-encrypted folder. As it looks, the 'previousSequence' does not get updated after deleting a locally appended file in a revert-encrypted folder, while this seems to be the expected/desired behaviour in these situations.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. I have seen that before as well, maybe 2) helps but I doubt it - a scan should have triggered a summary before that as well. I never quite pinned this issue down.

  2. Might be fixed (or being fixed) with Jacobs summary improvements.

  3. That's surprising - anything written to the db should get an updated previous sequence, regardless of why it's updated (delete on revert). Do you have any pointers (logs, code) that makes you suspect that happens?

Copy link
Member Author

@er-pa er-pa Feb 3, 2024 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. I did try that PR as well to see if it does help - doesn't seem like it but I'm not sure as there seems to be more going on
  2. Yes, I have some logs that point into that direction at least...well, initially it does get updated correctly at least, but it tends to (be able to) get reverted back to a prevSequence of before the revert-action at times. I added one extra logger in the IndexHandle loop to keep track of what sequences are being handled. It's not pretty but it does the job, otherwise the used build has zero changes.
### Base state (7 correctly synced files)

[MRIW7] 2024/02/03 12:48:03.659362 indexhandler.go:170: DEBUG: fset.Sequence: 25, s.prevSequence: 25

### Adding locally added file -> trigger manual scan

[MRIW7] 2024/02/03 12:48:45.761563 folder.go:208: DEBUG: receiveencrypted/afkhe-wfc4q@0x14000fae400 Running something due to request
[MRIW7] 2024/02/03 12:48:45.761590 folder.go:437: DEBUG: receiveencrypted/afkhe-wfc4q@0x14000fae400 scanning
[MRIW7] 2024/02/03 12:48:45.764893 indexhandler.go:170: DEBUG: fset.Sequence: 26, s.prevSequence: 25
[MRIW7] 2024/02/03 12:48:46.016125 indexhandler.go:170: DEBUG: fset.Sequence: 26, s.prevSequence: 26

#### Revert folder

[MRIW7] 2024/02/03 12:51:31.609341 folder_recvenc.go:42: INFO: Reverting unexpected items in folder "receive-encrypted" (afkhe-wfc4q) (receive-encrypted)
[MRIW7] 2024/02/03 12:51:31.610282 indexhandler.go:170: DEBUG: fset.Sequence: 27, s.prevSequence: 26
[MRIW7] 2024/02/03 12:51:31.861526 indexhandler.go:170: DEBUG: fset.Sequence: 27, s.prevSequence: 27

### Pause -> unpause folder

[MRIW7] 2024/02/03 12:52:15.963436 model.go:560: INFO: Paused folder "receive-encrypted" (afkhe-wfc4q) (receiveencrypted)
[MRIW7] 2024/02/03 12:52:17.562143 model.go:413: INFO: Ready to synchronize "receive-encrypted" (afkhe-wfc4q) (receiveencrypted)
[MRIW7] 2024/02/03 12:52:17.562161 model.go:560: INFO: Unpaused folder "receive-encrypted" (afkhe-wfc4q) (receiveencrypted)
[MRIW7] 2024/02/03 12:52:17.562213 folder.go:153: DEBUG: receiveencrypted/afkhe-wfc4q@0x14001186400 starting
[MRIW7] 2024/02/03 12:52:17.562230 folder.go:204: DEBUG: receiveencrypted/afkhe-wfc4q@0x14001186400 Scanning due to timer
[MRIW7] 2024/02/03 12:52:17.562240 folder.go:437: DEBUG: receiveencrypted/afkhe-wfc4q@0x14001186400 scanning
[MRIW7] 2024/02/03 12:52:17.562349 set.go:170: DEBUG: afkhe-wfc4q Snapshot()
[MRIW7] 2024/02/03 12:52:17.562392 set.go:170: DEBUG: afkhe-wfc4q Snapshot()
[MRIW7] 2024/02/03 12:52:17.574885 set.go:268: DEBUG: afkhe-wfc4q Get(N.syncthing-enc)
[MRIW7] 2024/02/03 12:52:17.575051 set.go:268: DEBUG: afkhe-wfc4q Get(N.syncthing-enc/VG)
[MRIW7] 2024/02/03 12:52:17.575203 set.go:268: DEBUG: afkhe-wfc4q Get(N.syncthing-enc/VG/8HVMNU6FH03TMSM9DPA90T9IG)
[MRIW7] 2024/02/03 12:52:17.575246 set.go:268: DEBUG: afkhe-wfc4q Get(5.syncthing-enc)
[MRIW7] 2024/02/03 12:52:17.575566 set.go:268: DEBUG: afkhe-wfc4q Get(5.syncthing-enc/IJ)
[MRIW7] 2024/02/03 12:52:17.575713 set.go:268: DEBUG: afkhe-wfc4q Get(5.syncthing-enc/IJ/862VC8Q0BT386UAT3RNVDTCOG)
[MRIW7] 2024/02/03 12:52:17.575790 set.go:268: DEBUG: afkhe-wfc4q Get(R.syncthing-enc)
[MRIW7] 2024/02/03 12:52:17.575976 set.go:268: DEBUG: afkhe-wfc4q Get(R.syncthing-enc/VP)
[MRIW7] 2024/02/03 12:52:17.576117 set.go:268: DEBUG: afkhe-wfc4q Get(R.syncthing-enc/VP/EUE6927PBLUPBD2D2MIKHSU2G)
[MRIW7] 2024/02/03 12:52:17.576156 set.go:268: DEBUG: afkhe-wfc4q Get(Q.syncthing-enc)
[MRIW7] 2024/02/03 12:52:17.576279 set.go:268: DEBUG: afkhe-wfc4q Get(Q.syncthing-enc/F2)
[MRIW7] 2024/02/03 12:52:17.576423 set.go:268: DEBUG: afkhe-wfc4q Get(Q.syncthing-enc/F2/4HMCEK08PD9R5EQRDK91HH0QG)
[MRIW7] 2024/02/03 12:52:17.576458 set.go:268: DEBUG: afkhe-wfc4q Get(8.syncthing-enc)
[MRIW7] 2024/02/03 12:52:17.576579 set.go:268: DEBUG: afkhe-wfc4q Get(8.syncthing-enc/91)
[MRIW7] 2024/02/03 12:52:17.576761 set.go:268: DEBUG: afkhe-wfc4q Get(8.syncthing-enc/91/22BA4NEPD26QSL93I79CNG25G)
[MRIW7] 2024/02/03 12:52:17.576799 set.go:268: DEBUG: afkhe-wfc4q Get(4.syncthing-enc)
[MRIW7] 2024/02/03 12:52:17.576959 set.go:268: DEBUG: afkhe-wfc4q Get(4.syncthing-enc/0N)
[MRIW7] 2024/02/03 12:52:17.577092 set.go:268: DEBUG: afkhe-wfc4q Get(4.syncthing-enc/0N/1QD6P2MH40917OA3AEK4PH2CG)
[MRIW7] 2024/02/03 12:52:17.577129 set.go:268: DEBUG: afkhe-wfc4q Get(3.syncthing-enc)
[MRIW7] 2024/02/03 12:52:17.577252 set.go:268: DEBUG: afkhe-wfc4q Get(3.syncthing-enc/1T)
[MRIW7] 2024/02/03 12:52:17.577414 set.go:268: DEBUG: afkhe-wfc4q Get(3.syncthing-enc/1T/RPJCAJKAL413HDJQ5AV5EBEN0)
[MRIW7] 2024/02/03 12:52:17.577447 set.go:170: DEBUG: afkhe-wfc4q Snapshot()
[MRIW7] 2024/02/03 12:52:17.577471 set.go:234: DEBUG: afkhe-wfc4q WithPrefixedHaveTruncated(7777777-777777N-7777777-777777N-7777777-777777N-7777777-77777Q4, "")
[MRIW7] 2024/02/03 12:52:17.577906 folder.go:506: DEBUG: receiveencrypted/afkhe-wfc4q@0x14001186400 finished scanning, detected 0 changes
[MRIW7] 2024/02/03 12:52:17.577931 folder.go:925: INFO: Completed initial scan of receiveencrypted folder "receive-encrypted" (afkhe-wfc4q)
[MRIW7] 2024/02/03 12:52:17.577945 folder.go:312: DEBUG: receiveencrypted/afkhe-wfc4q@0x14001186400 next rescan in 18h21m40.125256037s
[MRIW7] 2024/02/03 12:52:17.577955 set.go:170: DEBUG: afkhe-wfc4q Snapshot()
[MRIW7] 2024/02/03 12:52:17.577968 set.go:192: DEBUG: afkhe-wfc4q WithNeed(7777777-777777N-7777777-777777N-7777777-777777N-7777777-77777Q4)
[MRIW7] 2024/02/03 12:52:17.584992 set.go:170: DEBUG: afkhe-wfc4q Snapshot()
[MRIW7] 2024/02/03 12:52:17.585010 progressemitter.go:285: DEBUG: progress emitter: bytes completed for afkhe-wfc4q: 0
[MRIW7] 2024/02/03 12:52:17.585805 set.go:170: DEBUG: afkhe-wfc4q Snapshot()
[MRIW7] 2024/02/03 12:52:17.585865 model.go:951: DEBUG: model@0x14000198180 Completion(I6KAH76-66SLLLB-5PFXSOA-UFJCDZC-YAOMLEK-CP2GB32-BV5RQST-3PSROAU, "afkhe-wfc4q"): map[completion:100 globalBytes:7448 globalItems:7 needBytes:0 needDeletes:0 needItems:0 remoteState:unknown sequence:7]
[MRIW7] 2024/02/03 12:52:17.587487 set.go:170: DEBUG: afkhe-wfc4q Snapshot()
[MRIW7] 2024/02/03 12:52:17.587539 model.go:951: DEBUG: model@0x14000198180 Completion(I6KAH76-66SLLLB-5PFXSOA-UFJCDZC-YAOMLEK-CP2GB32-BV5RQST-3PSROAU, "afkhe-wfc4q"): map[completion:100 globalBytes:7448 globalItems:7 needBytes:0 needDeletes:0 needItems:0 remoteState:unknown sequence:7]
[MRIW7] 2024/02/03 12:52:18.589779 set.go:170: DEBUG: afkhe-wfc4q Snapshot()
[MRIW7] 2024/02/03 12:52:18.589809 progressemitter.go:285: DEBUG: progress emitter: bytes completed for afkhe-wfc4q: 0
[MRIW7] 2024/02/03 12:52:21.067488 model.go:951: DEBUG: model@0x14000198180 Completion(I6KAH76-66SLLLB-5PFXSOA-UFJCDZC-YAOMLEK-CP2GB32-BV5RQST-3PSROAU, "a7wgz-vfrev"): map[completion:100 globalBytes:0 globalItems:3 needBytes:0 needDeletes:0 needItems:0 remoteState:unknown sequence:3]
[MRIW7] 2024/02/03 12:52:21.069497 set.go:170: DEBUG: afkhe-wfc4q Snapshot()
[MRIW7] 2024/02/03 12:52:21.069556 progressemitter.go:285: DEBUG: progress emitter: bytes completed for afkhe-wfc4q: 0
[MRIW7] 2024/02/03 12:52:22.075274 set.go:385: DEBUG: afkhe-wfc4q IndexID(I6KAH76-66SLLLB-5PFXSOA-UFJCDZC-YAOMLEK-CP2GB32-BV5RQST-3PSROAU)
[MRIW7] 2024/02/03 12:52:22.075306 set.go:385: DEBUG: afkhe-wfc4q IndexID(7777777-777777N-7777777-777777N-7777777-777777N-7777777-77777Q4)
[MRIW7] 2024/02/03 12:52:22.076146 model.go:1348: DEBUG: Registering folder afkhe-wfc4q for I6KAH76
[MRIW7] 2024/02/03 12:52:22.076168 indexhandler.go:531: DEBUG: Not resuming index handler for device I6KAH76 and folder afkhe-wfc4q as none is paused and there is no start info
[MRIW7] 2024/02/03 12:52:22.076521 set.go:385: DEBUG: afkhe-wfc4q IndexID(7777777-777777N-7777777-777777N-7777777-777777N-7777777-77777Q4)
[MRIW7] 2024/02/03 12:52:22.076654 indexhandler.go:59: DEBUG: Device I6KAH76 folder "receive-encrypted" (afkhe-wfc4q) is delta index compatible (mlv=19)
[MRIW7] 2024/02/03 12:52:22.076682 set.go:385: DEBUG: afkhe-wfc4q IndexID(I6KAH76-66SLLLB-5PFXSOA-UFJCDZC-YAOMLEK-CP2GB32-BV5RQST-3PSROAU)
[MRIW7] 2024/02/03 12:52:22.077032 set.go:170: DEBUG: afkhe-wfc4q Snapshot()
[MRIW7] 2024/02/03 12:52:22.077065 set.go:192: DEBUG: afkhe-wfc4q WithNeed(7777777-777777N-7777777-777777N-7777777-777777N-7777777-77777Q4)
[MRIW7] 2024/02/03 12:52:22.077341 indexhandler.go:129: DEBUG: Starting index handler for afkhe-wfc4q to I6KAH76 at 127.0.0.1:22002-127.0.0.1:22001/tcp-server/TLS1.3-TLS_AES_128_GCM_SHA256/LAN-P10-5TGB0EIM3KPN063SGPH7PPEAH8 (slv=19)
[MRIW7] 2024/02/03 12:52:22.077417 set.go:170: DEBUG: afkhe-wfc4q Snapshot()
[MRIW7] 2024/02/03 12:52:22.077442 set.go:224: DEBUG: afkhe-wfc4q WithHaveSequence(20)
[MRIW7] 2024/02/03 12:52:22.077498 indexhandler.go:229: DEBUG: indexHandler@0x140001ea2a0 for afkhe-wfc4q to I6KAH76 at 127.0.0.1:22002-127.0.0.1:22001/tcp-server/TLS1.3-TLS_AES_128_GCM_SHA256/LAN-P10-5TGB0EIM3KPN063SGPH7PPEAH8: Sending 1 files (<341 bytes)

### prevSequence (in the IndexHandler) is the state of before the reverting action

[MRIW7] 2024/02/03 12:52:22.077526 indexhandler.go:170: DEBUG: fset.Sequence: 27, s.prevSequence: 25
[MRIW7] 2024/02/03 12:52:32.133462 set.go:170: DEBUG: afkhe-wfc4q Snapshot()
[MRIW7] 2024/02/03 12:52:32.133509 set.go:224: DEBUG: afkhe-wfc4q WithHaveSequence(26)
[MRIW7] 2024/02/03 12:52:22.328716 indexhandler.go:170: DEBUG: fset.Sequence: 27, s.prevSequence: 25
[MRIW7] 2024/02/03 12:52:32.133462 set.go:170: DEBUG: afkhe-wfc4q Snapshot()
[MRIW7] 2024/02/03 12:52:32.133509 set.go:224: DEBUG: afkhe-wfc4q WithHaveSequence(26)
[MRIW7] 2024/02/03 12:52:22.580022 indexhandler.go:170: DEBUG: fset.Sequence: 27, s.prevSequence: 25
[MRIW7] 2024/02/03 12:52:32.133462 set.go:170: DEBUG: afkhe-wfc4q Snapshot()
[MRIW7] 2024/02/03 12:52:32.133509 set.go:224: DEBUG: afkhe-wfc4q WithHaveSequence(26)
[MRIW7] 2024/02/03 12:52:22.831431 indexhandler.go:170: DEBUG: fset.Sequence: 27, s.prevSequence: 25
[MRIW7] 2024/02/03 12:52:32.133462 set.go:170: DEBUG: afkhe-wfc4q Snapshot()
[MRIW7] 2024/02/03 12:52:32.133509 set.go:224: DEBUG: afkhe-wfc4q WithHaveSequence(26)
[MRIW7] 2024/02/03 12:52:23.082581 indexhandler.go:170: DEBUG: fset.Sequence: 27, s.prevSequence: 25
[MRIW7] 2024/02/03 12:52:32.133462 set.go:170: DEBUG: afkhe-wfc4q Snapshot()
[MRIW7] 2024/02/03 12:52:32.133509 set.go:224: DEBUG: afkhe-wfc4q WithHaveSequence(26)
[MRIW7] 2024/02/03 12:52:23.334155 indexhandler.go:170: DEBUG: fset.Sequence: 27, s.prevSequence: 25
[MRIW7] 2024/02/03 12:52:32.133462 set.go:170: DEBUG: afkhe-wfc4q Snapshot()
[MRIW7] 2024/02/03 12:52:32.133509 set.go:224: DEBUG: afkhe-wfc4q WithHaveSequence(26)
[MRIW7] 2024/02/03 12:52:23.585569 indexhandler.go:170: DEBUG: fset.Sequence: 27, s.prevSequence: 25
[MRIW7] 2024/02/03 12:52:32.133462 set.go:170: DEBUG: afkhe-wfc4q Snapshot()
[MRIW7] 2024/02/03 12:52:32.133509 set.go:224: DEBUG: afkhe-wfc4q WithHaveSequence(26)
[MRIW7] 2024/02/03 12:52:23.837042 indexhandler.go:170: DEBUG: fset.Sequence: 27, s.prevSequence: 25
[MRIW7] 2024/02/03 12:52:32.133462 set.go:170: DEBUG: afkhe-wfc4q Snapshot()
[MRIW7] 2024/02/03 12:52:32.133509 set.go:224: DEBUG: afkhe-wfc4q WithHaveSequence(26)
[MRIW7] 2024/02/03 12:52:24.088660 indexhandler.go:170: DEBUG: fset.Sequence: 27, s.prevSequence: 25
[MRIW7] 2024/02/03 12:52:32.133462 set.go:170: DEBUG: afkhe-wfc4q Snapshot()
[MRIW7] 2024/02/03 12:52:32.133509 set.go:224: DEBUG: afkhe-wfc4q WithHaveSequence(26)
[MRIW7] 2024/02/03 12:52:24.339713 indexhandler.go:170: DEBUG: fset.Sequence: 27, s.prevSequence: 25
[MRIW7] 2024/02/03 12:52:32.133462 set.go:170: DEBUG: afkhe-wfc4q Snapshot()
[MRIW7] 2024/02/03 12:52:32.133509 set.go:224: DEBUG: afkhe-wfc4q WithHaveSequence(26)
[MRIW7] 2024/02/03 12:52:24.590524 indexhandler.go:170: DEBUG: fset.Sequence: 27, s.prevSequence: 25
[MRIW7] 2024/02/03 12:52:32.133462 set.go:170: DEBUG: afkhe-wfc4q Snapshot()
[MRIW7] 2024/02/03 12:52:32.133509 set.go:224: DEBUG: afkhe-wfc4q WithHaveSequence(26)
[MRIW7] 2024/02/03 12:52:24.841872 indexhandler.go:170: DEBUG: fset.Sequence: 27, s.prevSequence: 25
[MRIW7] 2024/02/03 12:52:32.133462 set.go:170: DEBUG: afkhe-wfc4q Snapshot()
[MRIW7] 2024/02/03 12:52:32.133509 set.go:224: DEBUG: afkhe-wfc4q WithHaveSequence(26)
[MRIW7] 2024/02/03 12:52:25.093186 indexhandler.go:170: DEBUG: fset.Sequence: 27, s.prevSequence: 25
[MRIW7] 2024/02/03 12:52:32.133462 set.go:170: DEBUG: afkhe-wfc4q Snapshot()
[MRIW7] 2024/02/03 12:52:32.133509 set.go:224: DEBUG: afkhe-wfc4q WithHaveSequence(26)
[MRIW7] 2024/02/03 12:52:25.344735 indexhandler.go:170: DEBUG: fset.Sequence: 27, s.prevSequence: 25
[MRIW7] 2024/02/03 12:52:32.133462 set.go:170: DEBUG: afkhe-wfc4q Snapshot()
[MRIW7] 2024/02/03 12:52:32.133509 set.go:224: DEBUG: afkhe-wfc4q WithHaveSequence(26)
[MRIW7] 2024/02/03 12:52:25.596336 indexhandler.go:170: DEBUG: fset.Sequence: 27, s.prevSequence: 25
[MRIW7] 2024/02/03 12:52:32.133462 set.go:170: DEBUG: afkhe-wfc4q Snapshot()
[MRIW7] 2024/02/03 12:52:32.133509 set.go:224: DEBUG: afkhe-wfc4q WithHaveSequence(26)
[MRIW7] 2024/02/03 12:52:25.847762 indexhandler.go:170: DEBUG: fset.Sequence: 27, s.prevSequence: 25
[MRIW7] 2024/02/03 12:52:32.133462 set.go:170: DEBUG: afkhe-wfc4q Snapshot()
[MRIW7] 2024/02/03 12:52:32.133509 set.go:224: DEBUG: afkhe-wfc4q WithHaveSequence(26)
[MRIW7] 2024/02/03 12:52:26.099432 indexhandler.go:170: DEBUG: fset.Sequence: 27, s.prevSequence: 25
[MRIW7] 2024/02/03 12:52:32.133462 set.go:170: DEBUG: afkhe-wfc4q Snapshot()
[MRIW7] 2024/02/03 12:52:32.133509 set.go:224: DEBUG: afkhe-wfc4q WithHaveSequence(26)
...

Copy link
Member

@imsodin imsodin Feb 10, 2024 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wow, thank! Still no idea how/why that happens, but great to have evidence of that, clearly pins down where something's going wrong.
Ah just saw this is now writen up in #9407 - thanks again!
Edit: Also maybe I now have an idea, thinking in progress :P

gui/default/syncthing/core/syncthingController.js
Comment on lines +3086 to +3088
// Deleting unexpected items won't trigger an index update.
// Subtract the deleted items from the total changed items.
return counts.receiveOnlyTotalItems - counts.receiveOnlyChangedDeletes > 0;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should be updated though? Reverting or manually deleting should replace the locally changed items with non-locally changed items in the db (from revert and/or scan), which in turn updates the counts. And that should reach the UI through the folder summary events. If that's not happening, we should fix that instead.

@er-pa
Copy link
Member Author

er-pa commented Jan 5, 2024

@imsodin Thanks for the feedback. It may surely be possible that I looked at this issue with wrongly made assumptions about how it is supposed to work (as I derived it a bit from the regular receive-only reverting mechanism). I'll have to look into it again, properly. Will get back about it.

@er-pa er-pa marked this pull request as draft January 14, 2024 13:47
@maximilize maximilize mentioned this pull request Apr 4, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@imsodin imsodin imsodin left review comments

At least 1 approving review is required to merge this pull request.

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
2 participants
@er-pa @imsodin