Testsuite für Import-Scheduler, Anhangsverarbeitung und Regelwerk,
inklusive Tenant-Scoping und nicht-konformer Server.
- tenant_scoping_test.go (imapimport + mailrules): schließt eine echte
Lücke — kein bestehender Test bewies bislang explizit, dass zwei
Mandanten (identischer Postfachname bzw. fehlende eigene Regel) sich
nicht gegenseitig beeinflussen.
- importtestgate/gate.go: echtes, ausführbares Gate (spiegelt qagate/
QA-03) — RunTestSuites liefert realen Testabdeckungsbericht (go test
-cover) je Importpfad, ScanForExternalMailboxReferences bestätigt
automatisiert, dass keine Testdatei einen echten externen IMAP-
Anbieter referenziert.
- Echten Bug beim eigenen Testlauf gefunden und behoben: die
t.Cleanup-Löschfilter in scheduler_test.go/engine_test.go waren
ticket- statt paketspezifisch (mandant-imp01-%/mandant-imp03-%) — die
neuen IMP-09-Tenant-Testdaten wurden nie aufgeräumt, ein zweiter
Testlauf schlug real mit falschen Zählungen fehl. Auf mandant-%
verallgemeinert.
Prüfungen (alle real durchgeführt, siehe mail/docs/IMP-09-PRUEFPROTOKOLL.md):
1. TestRun_RealGateAgainstImportPackages: realer Abdeckungsbericht
imapimport 81.5%, attachments 94.4%, mailrules 71.2%.
2. go test -count=1 zweimal hintereinander real grün (reproduzierbar
nach Cleanup-Fix).
3. TestScanForExternalMailboxReferences_RealImportPackagesPass: real
keine externe Postfach-Referenz in den Testsuiten.
Kein Umbau der geprüften Produktionslogik.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HhgFcLS8tYMhDJpP74C6AQ
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
Scheduler für periodischen IMAP-Postfach-Abruf mit UID-basiertem
Delta-Sync: neue Nachrichten erkennen, Zustandsänderungen abgleichen.
- imap (ING-01) minimal erweitert: Message.UID, MailboxStore.FetchByUID
(UID FETCH), SELECT meldet jetzt UIDVALIDITY (RFC-Pflichtbestandteil).
Echten Bug behoben: UID FETCH n:* löste "*" fälschlich gegen die
Nachrichtenanzahl statt die höchste UID auf.
- imapimport/state.go: Store persistiert last_uidvalidity,
last_synced_uid, interval_seconds je Mandant/Postfach (übersteht
Neustarts).
- imapimport/scheduler.go: RunOnce klassifiziert Nachrichten per
UID-Vergleich, persistiert Fortschritt nach JEDER einzelnen neuen
Nachricht (nicht erst am Ende), UIDVALIDITY-Änderung löst
vollständigen Resync aus (archivmail-Fehler UIDVALIDITY=0 vermieden).
- imapimport/client_real.go: echtes IMAP4rev1 über TCP
(LOGIN/SELECT/UID FETCH/LOGOUT).
Prüfungen (alle real durchgeführt, siehe mail/docs/IMP-01-PRUEFPROTOKOLL.md):
1. TestRunOnce_TwoConsecutiveRunsNoDuplicateImport: zweiter Lauf real
0 neue Nachrichten.
2. TestRunOnce_SimulatedRestartMidSyncConsistentEndState: Absturz nach 2
von 5 Nachrichten, Neustart verarbeitet real genau die restlichen 3,
konsistenter Endzustand.
3. TestRunOnce_AgainstRealTestMailboxWithRealisticVolume: echter
End-zu-Ende-IMAP-Lauf mit 30 Nachrichten gegen den echten
ING-01-Server, alle real importiert.
Kein Umbau: mail/internal/folderstate (ING-05) unverändert.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HhgFcLS8tYMhDJpP74C6AQ
