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
This commit is contained in:
co-authored by
Claude Sonnet 5
parent
e9947b1e28
commit
03c47d98f4
@@ -0,0 +1,58 @@
|
||||
# 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).
|
||||
Reference in New Issue
Block a user