[claude] Sync: duplicated ClientId causes silent, permanent divergence — add detection and reconciliation
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 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時間
- マージ済み PR（30日）
- 6
環境構築
このプロジェクトの環境構築ファイルはまだ確認していません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
sillsdev/harmony のほかの issue
-
enhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
メンテナーはふだん 1 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 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 日以内に返信
sillsdev/harmony の issue をすべて見る
似ている issue
-
area-ai untriaged
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
dotnet/extensions#7790 ·
メンテナーはふだん 1 日以内に返信
-
P2 testing
難易度 1/5 1時間未満 初心者へのやさしさ 90/100
メンテナーはふだん 1 日以内に返信
-
area-Infrastructure-coreclr os-ios os-maccatalyst os-tvos untriaged
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
dotnet/runtime#134766 · コメント 3 件 ·
メンテナーはふだん 1 日以内に返信
-
0 - Backlog Bug
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
BrighterCommand/Brighter#4444 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
メンテナーはふだん 1 日以内に返信