Aller au contenu

PD-171 — Rétrospective

1. Contexte

Champ Valeur
Story ID PD-171
Titre Synchronisation multi-device
Domaine backend-core
Projet backend
Date complétion 2025-12-30
Verdict ACCEPTÉ après correction

2. Métriques

Métrique Valeur
Tests passants 253
Écarts bloquants 2 (E-01, E-02)
Fenêtre d'évaluation 75ms
Types de conflits C1/C2/C3/C4
Règles de résolution R1-R4

3. Learnings clés

  • Distinction C1/C2 critique : Ce n'est pas un détail d'implémentation mais un invariant fonctionnel. La première version a échoué sur ce point précis.

  • Batch temporel = abstraction logique : En HTTP synchrone, chaque requête arrive individuellement. La "fenêtre d'évaluation" doit être implémentée rétrospectivement via l'historique.

  • Cas frontière base_version == canonical_version - 1 : C'est LE cas où la distinction C1/C2 se joue. Il mérite un traitement explicite et des tests dédiés.

  • Immuabilité DB = triggers PostgreSQL : L'application ne peut pas garantir seule l'append-only ; les triggers sont un prérequis de conformité.

4. Patterns applicables

Nouveau pattern : Détection C1 rétrospective

Quand une requête arrive avec base_version < canonical_version : 1. Si base_version < canonical_version - 1 → C2 (Stale) 2. Si base_version == canonical_version - 1 → consulter recentVersion dans la fenêtre - Si recentVersion.baseVersion == request.baseVersion → C1 (LWW) - Sinon → C2 (Stale)

Pattern existant : Append-only avec triggers

Cohérent avec PD-237 (Merkle) : les tables d'historique doivent être protégées par triggers SQL.

5. Signal CLAUDE.md

Priorité haute : Documenter le pattern de résolution de conflits C1/C2.

### Conflits sync multi-device — C1 vs C2 (2026-02-XX)

**C1 (Concurrent)** : Requêtes dans la même fenêtre d'évaluation → LWW
**C2 (Stale)** : Requêtes hors fenêtre → Rejet

Le cas `base_version == canonical_version - 1` nécessite une vérification rétrospective de l'historique pour distinguer C1 de C2.

**Erreur commune** : Traiter toute requête avec `base_version < canonical_version` comme C2.

6. Conclusion

PD-171 a nécessité deux itérations pour implémenter correctement la distinction C1/C2. La complexité venait de l'abstraction "batch temporel" qui ne correspond pas au modèle HTTP synchrone. Le pattern de détection rétrospective via l'historique est la solution retenue et doit être documentée pour les futures stories de synchronisation.


Rétrospective générée 2026-02-19 (Étape 10 batch backend-core)