Files

T

sysopsandClaude Sonnet 5 03c47d98f4 IMP-04: fehlerbehandlung-nicht-konformer-server

Defensive Fehlerbehandlung für nicht-RFC-konforme Mailserver beim
Import, mit dokumentierten Fallback-Pfaden statt Abbruch.

- client_real.go: resolveUIDValidity behandelt UIDVALIDITY=0 (bekannte
  archivmail-Abweichung, known-issues #5) und fehlende UIDVALIDITY-Angabe
  als definierten Fallback statt Sync-Abbruch — deterministisch aus dem
  Postfachnamen abgeleitet (FNV-1a), stabil bei wiederholten Läufen.
  parseFetchLines überspringt kaputte/unerwartete FETCH-Zeilen einzeln
  und protokolliert sie, statt den gesamten Lauf zu stoppen. Neuer
  Logger/WithLogger für nachvollziehbares Support-Logging.
- Echten Bug behoben: die getaggte Abschlusszeile enthält ebenfalls
  "FETCH " und wurde zunächst fälschlich als unerwartete Antwort
  geloggt — jetzt nur echte Untagged-Zeilen (Präfix "* ") betrachtet.

Prüfungen (alle real durchgeführt, siehe mail/docs/IMP-04-PRUEFPROTOKOLL.md):
1. TestResolveUIDValidity_ZeroTriggersDefinedFallbackNotAbort: Server
   meldet real UIDVALIDITY=0, Sync liefert real Fallback statt Fehler.
2. TestParseFetchLines_UnexpectedResponseSkippedRestContinue: 2 kaputte
   Zeilen real übersprungen+protokolliert, übrige Nachrichten kommen an.
3. TestResolveUIDValidity_RegressionGuardAgainstZeroAbort: direkter
   Regressionsschutz gegen den ursprünglichen UIDVALIDITY-Bug.

Kein Umbau: imap/folderstate/scheduler.go unverändert.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HhgFcLS8tYMhDJpP74C6AQ

2026-08-31 23:55:38 +02:00

3.6 KiB

Raw Blame History

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).

3.6 KiB Raw Blame History Unescape Escape