Folder-State-Verwaltung inklusive UIDVALIDITY/UIDNEXT-Handling (RFC 3501 §2.3.1.1), damit Clients und Importvorgänge konsistente Sichten erhalten. Direkte Vorbedingung für IMP-01. - store.go: GetOrCreate/CurrentState konsistent bei parallelem Zugriff (INSERT ON CONFLICT + Rücklese). NextUID vergibt UIDs atomar über UPDATE...RETURNING unter Zeilensperre, protokolliert jede Vergabe. Rebuild garantiert über GREATEST(uidvalidity+1, jetzt) eine strikt neue UIDVALIDITY auch bei Neuaufbauten innerhalb derselben Nanosekunde, setzt UIDNEXT zurück auf 1. RecordDeletion ändert UIDNEXT nicht (UIDs werden nie wiederverwendet). - Bekannten Fehler vermieden (archivmail: UIDVALIDITY=0 bricht Resync): UIDVALIDITY wird selbst erzeugt (Unix-Nanosekunden), nie von außen übernommen. - Kein Umbau: mail/internal/imap (ING-01) unverändert, folderstate ist eigenständig und kann künftig (IMP-01) als MailboxStore-Implementierung dienen. Prüfungen (alle real durchgeführt, siehe mail/docs/ING-05-PRUEFPROTOKOLL.md): 1. TestRebuild_ChangesUIDValidityOnSimulatedFolderRebuild: UIDVALIDITY real geändert, UIDNEXT real zurückgesetzt, Ereignis real protokolliert. 2. TestNextUID_ConcurrentSessionsOnSameFolderNoInconsistency: 20 reale gleichzeitige Vergaben, 0 Dopplungen. 3. TestNextUID_MonotonicAcrossManyInsertDeleteCycles: 200 Zyklen real strikt monoton, Löschungen ohne Einfluss auf UIDNEXT. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HhgFcLS8tYMhDJpP74C6AQ
10 lines
331 B
SQL
10 lines
331 B
SQL
CREATE TABLE IF NOT EXISTS mail_folder_state (
|
|
tenant_slug TEXT NOT NULL,
|
|
mailbox_name TEXT NOT NULL,
|
|
uidvalidity BIGINT NOT NULL,
|
|
uidnext BIGINT NOT NULL,
|
|
created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
|
|
updated_at TIMESTAMPTZ NOT NULL DEFAULT now(),
|
|
PRIMARY KEY (tenant_slug, mailbox_name)
|
|
)
|