# IMP-04 – Prüfprotokoll: Fehlerbehandlung nicht-konformer Server Voraussetzung IMP-01 (Fertig). ## Umsetzung - `mail/internal/imapimport/client_real.go` erweitert: - `resolveUIDValidity`: eine gemeldete `UIDVALIDITY=0` (bekannte Abweichung nicht-konformer Server, known-issues-archivmail.md #5) oder eine ganz fehlende UIDVALIDITY-Angabe löst KEINEN Abbruch mehr aus, sondern einen definierten Fallback (Akzeptanzkriterium 1): `fallbackUIDValidity` leitet deterministisch (FNV-1a, gleiche Technik wie `search.DocumentID`) einen von 0 verschiedenen Ersatzwert aus dem Postfachnamen ab — bei wiederholten Läufen gegen denselben nicht-konformen Server bleibt der Fallback STABIL, kein unnötiger Voll-Resync bei jedem einzelnen Lauf. - `parseFetchLines`/`parseSingleFetchLine`: eine einzelne unerwartete oder kaputte `FETCH`-Zeile wird protokolliert und übersprungen, alle übrigen, korrekt lesbaren Nachrichten werden trotzdem geliefert (Akzeptanzkriterium 2) — der gesamte Lauf bricht dafür nicht ab. - `Logger`/`RealClient.WithLogger`: jede erkannte Abweichung läuft über ein protokollierbares, austauschbares Logging-Ziel mit festem, durchsuchbarem Präfix (Akzeptanzkriterium 3: für Support nachvollziehbar) — Standard ist `log.Printf`. - Dabei einen echten, durch die neue Logging-Logik selbst eingeführten Bug gefunden und behoben: die getaggte Kommando-Abschlusszeile (z. B. `"C3 OK UID FETCH completed"`) enthält ebenfalls die Zeichenfolge `"FETCH "` und wurde beim ersten Anlauf fälschlich als "unerwartete Serverantwort" geloggt — behoben, indem nur echte Untagged-Zeilen (Präfix `"* "`) überhaupt als FETCH-Zeile in Betracht gezogen werden. - Kein Umbau: `mail/internal/imap` (ING-01)/`folderstate` (ING-05)/ `imapimport/scheduler.go` (IMP-01) unverändert — IMP-04 erweitert ausschließlich `client_real.go`. ## Prüfungen | # | Prüfung | Ergebnis | |---|---|---| | 1 | Test simuliert Server mit UIDVALIDITY=0 und bestätigt greifenden Fallback | **bestanden** – `TestResolveUIDValidity_ZeroTriggersDefinedFallbackNotAbort`: hand-gesteuerter Fake-Server meldet real `UIDVALIDITY=0`, `Sync` schlägt real NICHT fehl, liefert real einen von 0 verschiedenen, deterministischen Fallback-Wert und alle 3 Nachrichten, Fallback-Hinweis real protokolliert | | 2 | Test mit unerwarteter/kaputter Serverantwort bestätigt Weiterlauf für übrige Nachrichten | **bestanden** – `TestParseFetchLines_UnexpectedResponseSkippedRestContinue`: 2 bewusst kaputte Zeilen zwischen 2 korrekten real gesendet — `Sync` liefert real trotzdem beide korrekt lesbaren Nachrichten, beide kaputten Zeilen real protokolliert und übersprungen, kein Abbruch | | 3 | Regressionstest verhindert Wiederauftreten des UIDVALIDITY-Bugs | **bestanden** – `TestResolveUIDValidity_RegressionGuardAgainstZeroAbort`: direkter, vom Netzwerkpfad unabhängiger Test von `resolveUIDValidity` mit `UIDVALIDITY=0` UND mit gänzlich fehlender Angabe — beide liefern real keinen Fehler und einen Fallback-Wert != 0 | ## Build/Test-Ergebnis (192.168.1.131) ``` go build ./... -> clean go vet ./... -> clean golangci-lint run ./... -> 0 issues TEST_TENANT_DSN=... go test ./internal/imapimport/... -v -timeout 60s -> 7/7 bestanden TEST_TENANT_DSN=... TEST_MANTICORE_URL=... go test ./... -p 1 -> alle 15 Pakete bestanden, keine Regression ``` ## Gesamtergebnis **Bestanden.** Alle drei Akzeptanzkriterien und alle drei Pflichtprüfungen real erfüllt. Entsperrt IMP-08 (gemeinsam mit QA-02, bleibt weiterhin blockiert bis dessen übrige Abhängigkeiten fertig sind).