fix(sync): classify remote-only changes as remote-modified, not local-modified - #145
Merged
ClaudiaFang merged 1 commit intoAug 31, 2026
Conversation
…-modified SyncStatusService.classify() collapsed every two-sided diff into a direction-blind 'modified', which FileStatusAdapter then mapped to 'local-modified' regardless of which side actually changed. When only the remote side had moved (the exact shape a second client produces), the change was routed to the push bucket instead of pull, so it was silently skipped/conflicted instead of being pulled — caught by the new two-client-sync E2E suite (P0-1, P0-2) failing against the disposable Gitea provider in CI. classify() now takes optional localChanged/remoteChanged facts (derived from the tracked lastSyncedSha baseline) so it can tell "only remote changed" apart from "local changed" or "no baseline on record", and emits the already-modeled but previously unreachable 'remote-modified' status. FileStatusAdapter, ChangeActionPolicy.canDownload, and ChangeItem's inline Download button are wired through so a remote-modified row now routes to pull by default and offers manual download, same as remote-only. Also relabels the Source Control "Remote" filter chip to "Incoming" in all three locales: with remote-modified now reachable, "Remote Changes" read as "an existing file changed on the remote" and obscured that the bucket also holds brand-new remote-only files — "Incoming" covers both without implying a direction that isn't there.
|
ClaudiaFang
merged commit Aug 31, 2026
b186d35
into
claude/source-control-foundation
6 of 20 checks passed
Member
Author
|
🎉 This PR is included in version 1.6.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
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.
Summary
Fixes the CI failure on PR #129 (
CI / Provider E2E / gitea, run 33355671713): the newtwo-client-sync.e2e.test.tsP0-1/P0-2 tests caught a real production bug where a client's sync would silently drop a remote-only change to an already-tracked file, becauseSyncStatusService.classify()had no way to tell "only the remote side changed" apart from "the local side changed" — both collapsed into a direction-blind'modified', whichFileStatusAdapterthen mapped to'local-modified'(push), never pull.SyncStatusService.classify()now takes optionallocalChanged/remoteChangedfacts, derived from each file's trackedlastSyncedShabaseline, and emits the already-modeled but previously unreachable'remote-modified'status when only the remote side moved.FileStatusAdapter,ChangeActionPolicy.canDownload, andChangeItem's inline Download button are wired through, so aremote-modifiedrow now routes to pull by default and offers manual download — same asremote-only.remote-modifiednow reachable, "Remote Changes" read as "an existing file changed remotely" and obscured that the bucket also holds brand-newremote-onlyfiles.Test plan
npx eslint .— 0 errorsnpm run build— clean, including Obsidian 1.11.0 compat typechecknpx vitest run— 862/862 passed (68 files), including 3 pre-existing tests updated for the new, correct behavior and 2 new regression tests🤖 Generated with Claude Code