Self-hosted LiveSync : « rebuilt or corrupted » au 1er sync

Premier déploiement Obsidian LiveSync sur un CouchDB tout neuf. Plugin installé, conf OK, test connection vert. Je crée Note de test.md, j’attends 30s, côté serveur la DB n’a qu’un seul doc (le doc système d’init). Ma note n’est jamais arrivée.

Symptôme

Le plugin détecte bien le fichier local (STORAGE -> DB (plain) Note de test.md), mais au push :

The remote database has been rebuilt or corrupted since we have synchronized last time.
Fetch rebuilt DB, explicit unlocking or chunk clean-up is required.
Connexion au serveur impossible.

Aucune erreur réseau, le test connection passe, mais la réplication échoue en silence.

Cause

Au premier sync sur un CouchDB vide, le plugin :

1. Tente de récupérer les Synchronisation parameters distants → not found.
2. Les génère localement (dont un salt PBKDF2 pour le chiffrement E2E) et les stocke dans CouchDB.
3. Marque son instance comme device de référence pour ce salt.

À la session suivante, il compare le milestone distant à celui stocké en local. Si mismatch, il considère que la DB a été reconstruite par un autre device et refuse de push pour éviter des conflits. Le mismatch survient :

• Au 1er sync après init : pas de milestone local, params remote fraîchement créés → le plugin se méfie de sa propre création.
• Après un tofu apply qui recrée le container (volume préservé, params idem, mais state plugin désynchro).
• Quand un autre device (Android Setup URI) a généré ses params en parallèle.

Solution

Sur chaque device concerné (PC et Android) :

1. LiveSync settings → bouton « Mark this device as resolved » (« Marquer cet appareil comme résolu »). Souvent dans le bandeau d’avertissement en haut des settings, l’onglet Maintenance / Hatch / 🔧, ou Sync Settings → « Acknowledge » / « Unlock remote database ».
2. Cliquer → le plugin déverrouille la DB et re-synchronise.
3. Replicate now → ↑N (LIVE) ↓0 confirme.

Si Android a été setup APRÈS le PC sans jamais pull : Settings → « Fetch from remote » force un pull complet et réaligne le milestone.

Lessons learned

• Message alarmant, problème bénin : « rebuilt or corrupted » n’est qu’un check anti-conflits multi-device déclenché à tort au 1er sync. La DB n’est ni rebuilt ni corrompue.
• Test connection reste vert pendant tout le bug → on cherche à tort network/password/CORS, alors que la cause est le state interne du plugin.
• Diag rapide : Settings → Hatch → « Show log », chercher milestone ou rebuilt. Présent → « Mark as resolved » suffit.
• « Apply preferred tweak values » ne corrige PAS ce souci (il ne gère que les rule violations type customChunkSize). Il faut « Mark resolved → Replicate ».