Du öffnest Hermes, um die Session von gestern wiederherzustellen, und bekommst ein kaltes session not found — obwohl du dich klar daran erinnerst, dass es sie gibt. Schlimmer noch: state.db (die SQLite-Datenbank, in der Hermes den gesamten Session-Verlauf aufbewahrt) ist komplett beschädigt, und Monate an Gesprächen „verschwinden“. Früher war diese Problemklasse kaum zu diagnostizieren: Die Fehlermeldung verdeckte die eigentliche Ursache (beschädigte Datenbank), und das System schrieb munter in die defekte Datenbank weiter, sodass der Schaden sich lawinenartig vergrößerte. Ein Bündel von Fixes, gemerged am 30./31. August (PR #99513 und seine Schwester-PRs), gibt Hermes zum ersten Mal einen systematischen Umgang mit Datenbank-Korruption: erkennen, unter Quarantäne stellen, heilen, was heilbar ist — und es dir unmissverständlich sagen, wenn es nicht geht.

Warum es vorher so schwer zu diagnostizieren war

state.db ist eine SQLite-Datei — theoretisch robust, aber nach einem Stromausfall, einer vollen Platte, einem abgestürzten Prozess oder konkurrierenden Multi-Prozess-Zugriffen trotzdem beschädigbar. Früher war die Haltung von Hermes gegenüber Korruption: „So tun, als wäre nichts passiert“:

• Beim Lesen kaputter Daten zeigte die UI nur session not found und verschluckte die Tatsache, dass „die Datenbank beschädigt ist“;
• Eine strukturell defekte Datenbank akzeptierte weiterhin Schreibzugriffe — neue Daten flossen in einen kaputten Speicher, wie Wasser in einen leckenden Eimer;
• Eine 0-Byte-leere Datei wurde für eine „frische Datenbank“ gehalten und ganz normal geöffnet — bis der erste echte Schreibzugriff mit attempt to write a readonly database scheiterte;
• Bei mehreren Prozessen, die dieselbe Datenbank öffnen, konnte ein Prozess die gerade erst legitimerweise erzeugte leere Datenbank eines anderen Prozesses als beschädigt fehlklassifizieren und unter Quarantäne stellen.

Was dieses Bündel behebt

Sechs PRs, über vier Phasen: Erkennung, Quarantäne, Heilung und Schutz.

Korruption erkennen, statt so zu tun als ob

• „Corruption“ statt „session not found“ melden (PR #99529): Die Korruptionserkennung wandert in den Lesepfad, sodass das Problem mit einer klaren Meldung auftaucht statt mit einem irreführenden Fehler;
• Strukturell beschädigte Datenbanken akzeptieren keine Schreibzugriffe mehr (PR #99652): fail-closed — Schreibzugriffe verweigern, statt Daten in einen kaputten Speicher zu kippen;
• Lese-Verbindungen sind pro Datei begrenzt, nicht pro SessionDB-Instanz (PR #98691): Vorher hatte jede Instanz ihr eigenes Verbindungsbudget, sodass die Verbindungszahlen bei mehreren Instanzen davonliefen — ein Auslöser für Dateideskriptor-Erschöpfung und Abstürze.

0-Byte-Dateien unter Quarantäne stellen

• Eine abgeschnittene 0-Byte-state.db wird unter Quarantäne gestellt (PR #98017): Die leere Datei wird beim Start zur Seite gelegt, statt als normale Datenbank geöffnet zu werden;
• Cross-Process-Lock behebt die Quarantäne-Race (PR #99513, Teil-Cluster A): Die komplette Sequenz Prüfen → Quarantäne → Verbinden → Schema-Commit läuft jetzt unter einem Cross-Process-Lock, mit einem has_live_connection()-Guard, der „leere, aber legitimerweise in Benutzung befindliche“ Datenbanken schützt — ein Prozess kann die gerade erzeugte Datenbank eines Geschwisterprozesses nicht mehr unter Quarantäne stellen.

Den FTS-Volltextindex selbst heilen

• UnicodeDecodeError bricht die Index-Erkundung nicht mehr ab (PR #99513, Teil-Cluster B): Beschädigte Volltextsuch-Tabellen (FTS) können Decode-Fehler werfen, die früher die read-only Initialisierung und jeden dahinterliegenden Read-Endpunkt töteten; die Erkundungs- und Heilpfade fangen diese jetzt ab, und defekte FTS-Tabellen werden verworfen und neu angelegt.

Crash-Klassen-Races eliminieren

• Unsynchronisierte Reads auf der geteilten Writer-Verbindung sind weg (PR #99502): Diese Klasse konnte in Extremfällen Abstürze auf SIGSEGV-Niveau verursachen;
• close()-vs.-Hintergrundschreib-Races heilen sich selbst (PR #99509): Wenn die Schreibverbindung geschlossen wird, während noch Schreibvorgänge unterwegs sind, repariert sich das System selbst, statt still Daten zu verlieren.

Was das für dich bedeutet

Wenn dein Session-Verlauf jemals „auf mysteriöse Weise verschwunden“ ist, verändert dieses Bündel die gesamte Verarbeitungskette: Erkennung an erster Stelle → die defekte Datei unter Quarantäne → heilen, was heilbar ist (FTS-Tabellen) → und wenn es nicht heilbar ist, ein klarer Fehler — während niemals weiter in den kaputten Speicher geschrieben wird. Die Zuverlässigkeit der Session-Daten geht von „könnte eines Tages verschwinden“ zu „zumindest ist das Problem erklärt und der Schaden hört auf zu wachsen“.

Wann du es nutzen kannst

Diese PRs wurden am 30./31. August 2026 gemerged und sind alle nur auf main — noch in keinem Release. Aktualisiere auf das aktuelle main, um den vollen Schutz zu bekommen; falls du vorher auf session not found gestoßen bist oder Sessions verloren hast, lohnt es sich, die Fehlermeldungen nach dem Upgrade noch einmal zu lesen — sie sagen dir jetzt direkt, in welchem Zustand sich die Datenbank befindet.

Dein Session-Verlauf ist das Arbeitsgedächtnis zwischen dir und Hermes — seine Zuverlässigkeit verdient Pflege. Weitere Wege, Session-Daten zu schützen, findest du im Session-Speichern-&-Export-Guide und im Postmortem über 798 vergessene Nachrichten; wie Komprimierung mit dem Verlauf zusammenspielt, erklärt der One-Call-Kompaktierungs-Guide.