Synchronisation multi-device — Timeline C1 vs C2¶

Diagramme temporel (logique) illustrant la distinction entre conflit C1 — Concurrent Update Conflict et C2 — Stale Update Conflict définis dans la spécification PD-171.

sequenceDiagram
autonumber
participant A as Device A
participant B as Device B
participant BE as Backend (état canonique)
Note over BE: version_canonique = v
A->>BE: sync_request_id=A1<br>base_version=v
B->>BE: sync_request_id=B1<br>base_version=v
BE-->>A: applique A1<br>version := v+1 (état canonique)
BE-->>BE: enregistre B1 comme superseded<br>(C1 LWW sur même base_version)
BE-->>B: retourne état canonique v+1 (règle LWW)
Note over BE: autre mise à jour appliquée<br>version_canonique := v+2
B->>BE: sync_request_id=B2<br>base_version=v+1
BE-->>B: rejet C2 — Stale Update<br>(base_version < version_canonique)

Légende (5–6 lignes)
- C1 : deux requêtes partagent la même base_version avant l’engagement canonique ; LWW s’applique, la première écrit canonical, la seconde est marquée superseded et renvoie l’état résolu.
- C2 : une requête arrive après un incrément canonique ; base_version est strictement inférieure à version_canonique, la requête est rejetée comme stale.
- Le backend reste l’autorité unique : la concurrence est logique (mêmes entrées, décisions déterministes), sans hypothèse de threads ou verrous.
- La traçabilité (état canonical/superseded/rejected, rule_applied) permet d’auditer l’application des règles C1/C2 sans dépendre d’un timing physique.