Qualitäts-Review-Befund (b): Der Refresh-Token-Fix (9dc83f7) war richtig
analysiert, aber unvollständig – drei Restlücken gegen das matrix-SDK
6.2.0 verifiziert und geschlossen:
1. Client._handleSoftLogout ruft bei JEDEM Refresh-Fehler logout() auf,
und logout() macht 'finally clear()' – die lokale Session inkl.
Krypto-Schlüssel wird selbst bei einem transienten Netzwerkfehler
zerstört. Mit refreshToken:true laufen Access-Tokens künftig ab,
Refreshes werden Routine – das Restrisiko wäre also GESTIEGEN.
Fix: eigener onSoftLogout-Handler (soft_logout_guard.dart) mit
3 Versuchen, der nie wirft → SDK ruft nie logout() auf; bei
Dauerfehler bleibt der Client soft-logged-out und der nächste
Sync versucht es erneut (CLAUDE.md: Fehlerpfade dürfen NIE in
einem stillen Logout enden).
2. Das Push-Hintergrund-Isolate (background_push.dart) teilt sich die
pyramid.sqlite mit der Haupt-App; getEventByPushNotification()
ruft ensureNotSoftLoggedOut() auf. Ohne Guard hätte ein
Refresh-Fehler im Isolate (inkl. Token-Rotations-Race mit der
Haupt-App) die Session der GESAMTEN App gelöscht. Guard auch dort
gesetzt; das Race heilt der Retry, weil refreshAccessToken() den
Token bei jedem Versuch frisch aus der DB liest.
3. isLoggedInProvider behandelte softLoggedOut wie ausgeloggt – die UI
wäre bei jedem Routine-Token-Refresh kurz auf den Login-Screen
gesprungen (für Nutzer nicht von einem 'Random Logout' zu
unterscheiden). Jetzt zählt nur echtes loggedOut.
UNGETESTET (Pi) – gehört zum selben ausstehenden PC-Praxistest wie
9dc83f7: Login → Nachrichten → Logout → Neu-Login → alte Nachrichten
lesbar; zusätzlich auth_log.txt auf die neuen Guard-Einträge prüfen.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Beide Logout-Bestätigungsdialoge prüfen jetzt vorab per neuem
isKeyBackupMissing(client) (bootstrap_dialog.dart), ob Cross-Signing/
Key-Backup eingerichtet ist. Fehlt es, zeigt der Dialog eine
Klartext-Warnung: alte verschlüsselte Nachrichten wären nach dem
Logout auf keinem Gerät mehr lesbar. Ohne fehlendes Backup bleibt der
bisherige Text unverändert.
Ursache gefunden: Ohne Refresh-Token eskaliert das matrix-SDK jeden
Soft-Logout (z. B. abgelaufenes Access-Token, M_UNKNOWN_TOKEN mit
soft_logout=true) automatisch zu einem echten, destruktiven Logout —
_handleSoftLogout() versucht refreshAccessToken(), das ohne
gespeicherten Refresh-Token sofort mit "No refresh token available"
scheitert, und ruft danach client.logout() auf (client.dart:2374-2384
im matrix-Paket, Version 6.2.0).
Mit refreshToken: true beim Login bekommt der Client vom Server einen
Refresh-Token und kann einen Soft-Logout künftig durch stillen
Token-Refresh überstehen, statt die Sitzung zu zerstören. Falls der
Server keine Refresh-Tokens unterstützt, bleibt das Verhalten
unverändert (response.refreshToken ist dann null).
Wichtig: gilt nur für neue Logins. Bereits eingeloggte Geräte (z. B.
Uta) profitieren erst nach einmaligem Neu-Login. Zur Diagnose siehe
den mit 63e4919 eingeführten AuthLog.
UNGETESTET (Pi, kein GUI/Login hier möglich) – nächster PC-Lauf muss
den vollen Kreislauf prüfen: Login → Nachrichten → Logout → erneuter
Login → alte verschlüsselte Nachrichten noch lesbar?
6 Wochen uncommittete Arbeit (Voice-Channels, LiveKit-Manager, Settings-Modal u.v.m.)
als ein WIP-Commit gesichert, damit nichts verloren geht und der Pi den aktuellen
Stand klonen kann. Thematische Aufarbeitung: siehe ROADMAP M0.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CPrAGBxBT6GfPXzeWQ4AXb
Bernd Steckmeister