Vous ouvrez Hermes pour récupérer la session d’hier et vous obtenez un glacial session not found — alors que vous vous souvenez très bien qu’elle existe. Pire : state.db (la base SQLite dans laquelle Hermes conserve tout l’historique des sessions) se corrompt entièrement et des mois de conversations « disparaissent ». Par le passé, cette classe de problèmes était presque impossible à diagnostiquer : le message d’erreur masquait la vraie cause (la corruption de la base) et le système continuait d’écrire dans la base cassée, faisant boule de neige. Une série de correctifs fusionnés du 30 au 31 août (PR #99513 et ses PR voisines) donne enfin à Hermes une méthode systématique pour gérer la corruption de base de données : la détecter, la mettre en quarantaine, réparer ce qui peut l’être — et vous le dire clairement quand ce n’est pas possible.

Pourquoi c’était si difficile à diagnostiquer avant

state.db est un fichier SQLite — robuste en théorie, mais toujours corruptible après une coupure de courant, un disque plein, un processus qui plante ou des ouvertures concurrentes par plusieurs processus. Par le passé, l’attitude de Hermes face à la corruption était « faire comme si rien ne s’était passé » :

• À la lecture de données corrompues, l’interface n’affichait que session not found, avalant le fait que « la base de données est corrompue » ;
• Une base structurellement cassée continuait d’accepter les écritures — de nouvelles données coulaient dans un stockage cassé, comme on remplit un seau percé ;
• Un fichier vide de 0 octet était pris pour une « base toute neuve » et ouvert normalement — jusqu’à ce que la première vraie écriture échoue avec attempt to write a readonly database ;
• Avec plusieurs processus ouvrant la même base, un processus pouvait prendre la base vide légitimement tout juste créée par un autre processus pour une base corrompue et la mettre en quarantaine.

Ce que cette série corrige

Six PR, réparties sur quatre phases : détection, quarantaine, réparation et protection.

Détecter la corruption au lieu de faire semblant

• Signaler « corruption » au lieu de « session not found » (PR #99529) : la détection de corruption remonte dans le chemin de lecture, si bien que le problème remonte à la surface avec un message clair au lieu d’une erreur trompeuse ;
• Les bases structurellement corrompues cessent d’accepter les écritures (PR #99652) : échec en mode fail-closed — refuser d’écrire plutôt que de verser des données dans un stockage cassé ;
• Les connexions de lecture sont plafonnées par fichier, pas par instance de SessionDB (PR #98691) : auparavant, chaque instance disposait de son propre budget de connexions, si bien que le nombre de connexions s’emballait avec plusieurs instances — un déclencheur d’épuisement des descripteurs de fichiers et de crashs.

Mettre en quarantaine les fichiers de 0 octet

• Un state.db tronqué à 0 octet est mis en quarantaine (PR #98017) : le fichier vide est écarté au démarrage au lieu d’être ouvert comme une base normale ;
• Un verrou inter-processus corrige la course à la quarantaine (PR #99513, sous-groupe A) : toute la séquence vérification → quarantaine → connexion → commit du schéma s’exécute désormais sous un verrou inter-processus, avec une garde has_live_connection() qui protège les bases « vides mais légitimement en cours d’utilisation » — un processus ne peut plus mettre en quarantaine la base tout juste créée par un autre.

Auto-réparation de l’index FTS plein texte

• UnicodeDecodeError ne casse plus la sonde d’index (PR #99513, sous-groupe B) : les tables FTS (full-text search) corrompues peuvent lever des erreurs de décodage qui, auparavant, tuaient l’initialisation en lecture seule et tous les points de lecture en aval ; les chemins de sonde et de réparation interceptent désormais ces erreurs, et les tables FTS cassées sont supprimées puis recréées.

Éliminer les courses de classe crash

• Les lectures non synchronisées sur la connexion d’écriture partagée ont disparu (PR #99502) : cette classe pouvait provoquer des crashs de niveau SIGSEGV dans les cas extrêmes ;
• Les courses close() vs écritures en arrière-plan s’auto-réparent (PR #99509) : lorsque la connexion d’écriture se ferme pendant que des écritures sont encore en vol, le système se répare lui-même au lieu de laisser les données se perdre en silence.

Ce que cela change pour vous

Si votre historique de session a déjà « mystérieusement disparu », cette série change toute la chaîne de traitement : détection en amont → quarantaine du mauvais fichier → réparation de ce qui est réparable (tables FTS) → et, quand la réparation est impossible, une erreur claire — sans jamais continuer à écrire dans le stockage cassé. La fiabilité des données de session passe de « pourrait disparaître un jour » à « au moins le problème est expliqué et les dégâts cessent de croître ».

Quand pouvez-vous l’utiliser

Ces PR ont été fusionnées du 30 au 31 août 2026 et sont toutes sur main uniquement — pas encore dans une release. Mettez à jour vers le dernier main pour bénéficier de la protection complète ; si vous avez déjà rencontré session not found ou perdu des sessions, les messages d’erreur méritent d’être relus après la mise à jour — ils vous indiquent désormais directement l’état de la base.

Votre historique de session est la mémoire de travail entre vous et Hermes — sa fiabilité mérite qu’on en prenne soin. Pour d’autres façons de protéger les données de session, consultez le guide de sauvegarde et d’export des sessions et le post-mortem de l’amnésie des 798 messages ; l’interaction entre la compression et l’historique est traitée dans le guide de compaction en un appel.