Vault einrichten: „Verbinden“ nach Abbruch meldet „Anmeldung abgelaufen“ — Fortsetzen nutzt die 30-Minuten-Anmeldung statt der gespeicherten Zugangsdaten #245
Labels
No labels
herkunft/alpha-feedback
status
blockiert
status
zu-testen
typ
bug
typ
docs
typ
enhancement
typ
feature
typ
idea
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
iris/Iris#245
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Befund
Beim Einrichten eines großen Vaults (Repo
iris-vault-noch-ein-Test, 29,7 GiB, davon ~29 GiB Git-LFS) bricht der Klon ab („Die Verbindung wurde unterbrochen. Das bisher Geladene bleibt erhalten: Drücke noch einmal ‚Verbinden‘“). Ein erneuter Klick auf Verbinden meldet sofort „Die Anmeldung ist abgelaufen. Bitte melde dich neu an.“ — obwohl das gespeicherte Forgejo-Token noch gültig ist. Ein Neustart des Einrichtens beginnt von vorn und hängt nach langer Zeit wieder an derselben Stelle.Gefunden beim Test der Vault-Synchronisation zwischen mehreren Iris-Instanzen (Mac-VM unter UTM, Iris 2.0.1 Build 1, macOS 26.6.1).
Ursache der Meldung (gemessen im Code)
VaultForge.pendingTimeToLive = 1800(VaultSyncCore.swift:1160): Die Anmeldung des Dialogs liegt nur im Speicher und gilt 30 Minuten ab dem Login.configure(useLogin: true)(VaultSyncController.swift:514) verlangt bei jedem „Verbinden“VaultForge.currentPending(). Ist sie älter als 30 Minuten →409 login_expired→ die Meldung oben.resumable: trueund behält Klon, Anhänge und Zugangsdaten, „damit ‚Vault verbinden‘ fortsetzen kann“. Das Fortsetzen nutzt die gespeicherten Zugangsdaten aber nicht, sondern wieder die 30-Minuten-Anmeldung.Ein Klon mit ~29 GiB dauert Stunden. Die Anmeldung ist beim Fortsetzen also praktisch immer abgelaufen; das Versprechen „Fortsetzen“ lässt sich bei einem großen Vault nicht einlösen. Mit UTM hat das nichts zu tun.
Gemessen auf der VM
vault-sync-credentials.jsonenthält ein Token;GET /api/v1/userdamit → 200 (gültig, nicht widerrufen). Die Meldung stammt also nicht von Forgejo..git(kein Checkout), Markeiris-setup-incomplete;.git/lfs29 GiB.batch→ok, anschließender Abruf je Objekt (Range 0–0) → HTTP 206. Auf Forgejo-Seite ist nichts kaputt, es hängt auch nicht an einem einzelnen Objekt.Noch offen
syncLog.debugwird nicht persistiert. Nötig:log stream --level debug --predicate 'process == "Iris"'während eines Versuchs..git/lfs/objectsvor/nach vergleichen).Vorschlag
resumable) soll mit den gespeicherten Zugangsdaten arbeiten, nicht mit der 30-Minuten-Anmeldung; die Anmeldung braucht nur der erste Schritt (Repo wählen/anlegen).Nicht geprüft
Die Mac-App-Version auf der VM gegenüber den Fixes aus #234 und #243; ein Test auf echter Hardware (steht aus).
PR #246 gemergt: fix(vault-sync): Fortsetzen mit gespeicherten Zugangsdaten, wenn die Anmeldung abgelaufen ist (iris/Iris#245)
http://docker:3000/iris/Iris/pulls/246
Commits:
Stand: Fortsetzen mit gespeicherten Zugangsdaten
Befund: Das Einrichten (Klon + ~29 GiB LFS) dauert Stunden, die Forgejo-Anmeldung (
forge/login) liegt nur 30 Minuten im Speicher. Nach einem Abbruch lieferte „Verbinden“ deshalb409 login_expired, obwohl die Zugangsdaten gespeichert und das Token gültig waren.Geändert:
configure(use_login: true)nutzt bei abgelaufener Anmeldung die gespeicherten Zugangsdaten, aber nur wenn (1) die Markeiris-setup-incompleteda ist, (2)remote_urlauf dasselbe Repository wie das Remote des begonnenen Klons zeigt und (3) der Server dem Scope der gespeicherten Zugangsdaten entspricht. Sonst bleibt409 login_expired. Mac (VaultSyncSetup.resumableLogin,VaultSyncController), Linux (_resumable_login), Wire-Doku.Geprüft:
scripts/test-vault-sync-core.sh: 280 Prüfungen, 0 Fehler (vorher 274): gleiches Repo geht, anderes Repo → nil, ohne Zugangsdaten → nil, nach fertigem Einrichten → nil.tests/test_vault_git_sync.py: 91 grün. Neuer Test schlägt ohne Fix fehl (Mutationsprüfung).Nicht geprüft:
VaultSyncController.swiftnicht kompiliert (kein xcodebuild möglich) – bitte in Xcode bauen.Offen: Ursache des Hängens (Debug-Log:
log stream --level debug --predicate 'process == "Iris"'), ob ein Neustart vorhandene LFS-Objekte wiederverwendet, ob die VM-Version #234/#243 enthält, UI: Dialog sagt „Bitte melde dich neu an“ ohne Login-Button.PR #130 gemergt: fix(vault-sync): Fortsetzen mit gespeicherten Zugangsdaten, wenn die Anmeldung abgelaufen ist (iris/Iris#245)
http://docker:3000/iris/iris-linux-server/pulls/130
Commits:
Stand Linux-Server: Fortsetzen mit gespeicherten Zugangsdaten
Gegenstück zu PR #246 (Mac).
vault_git_sync.configure(use_login=True)fällt bei abgelaufener Anmeldung auf_resumable_loginzurück (Markeiris-setup-incomplete, gleiches Repo wie Remote des Klons, Server = Scope der gespeicherten Zugangsdaten), sonst409 login_expired.Geprüft:
tests/test_vault_git_sync.py91 grün; neuer Testtest_resume_with_an_expired_login_uses_the_stored_credentialsschlägt ohne Fix fehl.Nicht geprüft: nicht auf iris-server deployt, kein Test mit echtem Forgejo/29-GiB-Klon. Das Hängen bei ~97 % bleibt offen.
PR #135 gemergt: docs(wire): Fortsetzen mit gespeicherten Zugangsdaten bei abgelaufener Anmeldung (iris/Iris#245)
http://docker:3000/alf/2ndbrain/pulls/135
Commits:
Stand Wire-Doku
02-Wire-Protokoll.md: Tabelle undforge/login-Absatz beschreiben die Fortsetzen-Regel (Markeiris-setup-incomplete, gleiches Repo, gleicher Server) für409 login_expired. Reine Doku, nichts geprüft außer Abgleich mit dem Code in #246 und dem Linux-PR.