Hold a group's deletes until its snapshots are written, from an attached viewer - #887
Merged
Merged
Conversation
…hed viewer A snapshot moving inline arrives as a patch plus a delete of the verified file it replaces. "Accept all in <solution>" in a viewer attached to someone else's queue posted one accept per member, the delete included, and the owner carried each out as asked. A patch it could not write - the call site moved since the run - was dropped as a stale one is, and the verified file went anyway, leaving no copy of the snapshot. The owning viewer's group accept and every accept-all already hold deletes for this; this path did not. The attached viewer now sends the group as one ordered step: moves, then snapshots, then the deletes only once every snapshot is in the source. Whether one is cannot be read from the reply's ok, which a stale patch also gets, nor from a listing, where a stale patch is gone just as an applied one is. So an accept reply now says so: written, set by the tray and by an owning viewer from the applier's own answer. A reply without it, from an owner that predates it, holds the deletes, which stay queued to be accepted on their own.
This was referenced Sep 23, 2026
Merged
Merged
Merged
Merged
Merged
This was referenced Sep 24, 2026
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two commits: removing the done items from
todo.md, then the one open data-loss item.The data loss
A snapshot moving inline arrives as a patch plus a delete of the verified file it replaces. "Accept all in " in a viewer attached to someone else's queue went wrong like this:
DispatchGroupposted oneAcceptper member, the delete included.The owning viewer's group accept, and every accept-all since #878, already hold deletes for this. This path didn't.
The fix
OwnerLink.PostAcceptGroup). It accepts moves, then snapshots, and only then the deletes, and only if every snapshot is in the source.okcan't say whether a snapshot is in the source, because a stale patch getsoktoo. A listing can't either: a stale patch is gone from it just as an applied one is. So an accept reply now carrieswritten, set from the applier's own answer by both owners: the tray (OwnedInlineHost) and an owning viewer (MessageHandler).Tests
AttachedViewerTests.AGroupAcceptHoldsItsDeletesWhenASnapshotWasNotWrittenandAGroupAcceptDeletesOnceItsSnapshotsLandedgo through the real menu, a realOwnerLinkand an owning viewer. The first fails againstmain'sDispatchGroup, with the delete carried out.TrayViewerSyncTest.AViewerGroupAcceptHoldsItsDeletesWhenTheTrayCouldNotWriteASnapshotandAViewerGroupAcceptCarriesOutItsDeletesOnceTheTrayWroteTheSnapshotsuse the tray as owner, the arrangement it sets up at login.ViewerProtocolTests.AnAcceptSaysWhetherTheSnapshotWasWrittencovers the new field on the wire, and a reply without it.The full solution passes locally in Release: 2,040 passed, 24 skipped.