[claude] Sync: duplicated ClientId causes silent, permanent divergence — add detection and reconciliation
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 30/100
- Issue 类型
- 缺陷
- 描述清晰度
- 需要澄清
- 活跃度
- 冷清
- 技术栈
- csharp, sqlite
调研方向
先阅读 SyncState 和 QueryHelpers.GetMissingCommits，以了解基于时间戳的交换机制，然后跟踪 AddRangeFromSync 和 SnapshotWorker，分析其在报告的故障中的执行过程。该 issue 提议检测并协调重复的 ClientIds，但没有确定修复策略；完成条件是确定一种达成共识的行为，能够检测分歧并防止提交滞留导致的故障。
由索引模型根据 Issue 内容生成。
描述
[Claude-drafted]
Sync exchanges commits purely on (ClientId → latest commit timestamp) (SyncState, QueryHelpers.GetMissingCommits). This assumes each ClientId is a single writer with append-only history. If two replicas ever write under the same ClientId (copied SQLite file, restored device backup), their histories fork and commits are permanently stranded in both directions — each side believes the other already has everything below its head. Nothing detects this: commit hashes never cross the wire ([JsonIgnore]), hash only id + parentHash, and are rewritten locally.
Repro: copy a project DB to a second client, edit + sync on both. The project eventually becomes unsyncable: an edit arrives for an entity whose creating commit is stranded, and SnapshotWorker throws on every subsequent sync.
Proposal (layered):
- Tripwire: in
AddRangeFromSync, receiving a commit authored by the local ClientId that isn't already in the local DB proves the ID is duplicated → surface loudly; the app should switch to a fresh ClientId so the fork stops growing. - Detect: extend
SyncStateentries with a commit count + order-independent digest of that client's commit IDs, compared over the shared range (≤ the lower head). Mismatch ⇒ divergence, even when heads differ. Must stay compatible with timestamp-only clients. - Repair: on divergence for a ClientId, exchange that client's full commit-ID list, diff, send missing commits both ways.
AddRangeFromSyncalready handles past-insertion (dedup, hash rewrite, snapshot replay), so the merge converges. Open question: auto-repair with loud logging vs. requiring user attention.
Prevention (keeping writer identity out of the copyable DB) is the app's job: sillsdev/languageforge-lexbox#2431.
- 主要语言
- C#
- 星标
- 14
- 派生
- 4
- 平均合并
- 2 天 18 小时
- 30 天内合并 PR
- 6
环境准备
我们还没有检查这个项目的环境配置文件。先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
sillsdev/harmony 的其他 Issue
-
enhancement
难度 2/5 1-3 小时 新手友好度 84/100
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 35/100
维护者通常 1 天内回复
-
Data bug
难度 4/5 3-5 天 新手友好度 55/100
sillsdev/harmony#105 · 2 条评论 ·
维护者通常 1 天内回复
-
bug
难度 4/5 3-5 天 新手友好度 55/100
维护者通常 1 天内回复
-
enhancement
难度 3/5 1-2 天 新手友好度 58/100
维护者通常 1 天内回复
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 78/100
microsoft/fluentui-blazor#5364 ·
维护者通常 1 天内回复
-
.NET triage
难度 2/5 1-3 小时 新手友好度 74/100
microsoft/agent-framework#8811 ·
维护者通常 1 天内回复
-
.NET Docs
难度 1/5 1 小时以内 新手友好度 82/100
getsentry/sentry-dotnet#5637 · 1 条评论 ·
维护者通常 2 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
QuantConnect/Lean#9842 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 82/100
NethermindEth/nethermind#14012 ·
维护者通常 1 天内回复