Modèle de conflits

[64ix]

Question

Quel modèle de résolution de conflits quand deux machines modifient la même donnée ?

Options : last-write-wins par ligne (les updatedAt existent quasi partout), CRDT (Yjs/Automerge), serveur autoritaire avec réserve, merge manuel avec UI.

Contexte : perso mono-utilisateur — les conflits réels sont rares (on travaille sur une machine à la fois, l'offline est l'exception). LWW suffit-il ? Où vit l'état de vérité (serveur, dernière écriture horodatée) ? Qu'est-ce que le mécanisme choisi (« Choix du mécanisme de sync ») rend possible/impossible ?

Parent

Part of #MAPNUM

[64ix]

Résolution (grilling réduit HITL + 2 recherches : patterns d'écriture du code, pratique LWW web) — modèle acté : LWW ligne entière, silencieux, versions serveur autoritatives.

Décision utilisateur : conflits 100 % silencieux (la dernière écriture gagne, rien n'est montré). La détection (« modifiée des deux côtés ») reste ajoutable plus tard sans rien casser — les versions serveur par ligne sont déjà stockées.

Décisions techniques (vérifiées) :

• Versions serveur autoritatives : compteur monotone par espace, estampillé transactionnellement dans le même batch que les écritures (pattern Replicache : UPDATE counter SET version = version + 1 RETURNING version dans db.batch() — jamais de timestamp client pour l'ordre, jamais d'AUTOINCREMENT hors transaction : les deux sont documentés comme sources de désync persistante).
• Clock de sync locale par trigger SQLite (sync_ts ms, migration) : push = sync_ts > lastPushed par table autorisée — affine Choix du mécanisme de sync #114 (updatedAt inutilisable : formats mixtes texte-seconde vs ISO-ms, app_settings.updatedAt jamais rafraîchi, project_remotes sans timestamp). Aucune interception du write-path.
• Tombstones : suppression = row avec flag deleted à une nouvelle version ; LWW uniforme (le delete bat l'édition plus vieille, une édition plus récente ressuscite) ; GC quand la version-min des devices tirés dépasse la version du tombstone + cap 90 j ; jamais de hard-delete relais avant que tous les devices aient tiré. Reset-à-défaut des app_settings = tombstone normal (la row supprimée arrive en deleted).
• Push-then-pull : les rows locales non poussées ne sont jamais écrasées par un pull ; ordre strict push (ack) → pull. Jamais rejeter un push stale : accept-and-overwrite par ordre de réception serveur (rejeter = boucles de retry, footgun documenté PowerSync/Replicache) ; tout push est ack.
• tasks.boardRank exclu du payload : index fractionnaire dérivé de l'état de colonne au moment du drop — deux drops concurrents = rangs dupliqués, LWW = ordres entrelacés. État dérivé machine-local (même classe que view-state).
• project_remotes : correction de Périmètre table-par-table de la sync #112 — sync initiale seule (avec la création/attachement du projet, hint pour l'auto-attach Remapping des chemins absolus macOS ↔ Windows #113), pas de sync continue : c'est un cache machine-dérivé réécrit toutes les 5 min avec delete-sweep → la sync continue créerait une guerre d'écritures (A supprime le remote que B a en plus, B le ré-ajoute, boucle).
• JSON versionnés (linkedIssues, configs automations, conversations.config) : transport en raw strings, jamais de read-modify-write d'un blob future-version (les callers reçoivent null — un round-trip détruirait la donnée, cf. updateLinkedIssueRole). Écriture gardée : ne pas écraser un blob local illisible par un plus ancien.
• Pas de merge per-column (YAGNI — mono-utilisateur, Electric doc : « conflicts are extremely rare »). PATCH per-field reste un upgrade possible.
• Enveloppe E2E (pour Chiffrement E2E et clés #117) : métadonnées en clair (space, row_id, version, op_type, deleted) + corps chiffré — le relais applique le LWW sans lire le contenu ; fuite acceptable : ids, versions, patterns de suppression.

Conséquences : #118 — retirer l'item ouvert « traitement des conflits » (acté : silencieux, pas de notification) ; #117 — l'enveloppe ci-dessus est le contrat ; #119 (spec) — triggers sync_ts (migration), side-table des versions appliquées par row, ordre push-pull, GC tombstones, payload builder excluant boardRank, mode initial-only pour project_remotes.