sysopsandClaude Sonnet 5
0d3779d03e
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
58 lines
3.1 KiB
Markdown
58 lines
3.1 KiB
Markdown
# ING-05 – Prüfprotokoll: Folder-State & UIDVALIDITY-Handling
|
||
|
||
Voraussetzung ING-01 (Fertig). ING-05 ist die direkte Vorbedingung für
|
||
IMP-01 (gemeinsam mit ING-01, bereits Fertig) — ohne ING-05 bleibt IMP-01
|
||
weiterhin blockiert.
|
||
|
||
## Umsetzung
|
||
|
||
- `mail/internal/folderstate/store.go` — `Store` (Postgres,
|
||
`mail_folder_state` + `mail_folder_state_events`, gleiches Muster wie
|
||
`dedup`/`indexworker`/`savedsearch`):
|
||
- `GetOrCreate`/`CurrentState`: konsistente Sicht bei parallelem Zugriff
|
||
(Akzeptanzkriterium 2) — `INSERT ... ON CONFLICT DO NOTHING` +
|
||
Rücklese, kein Lese-dann-Schreib-Fenster.
|
||
- `NextUID`: vergibt UIDs atomar über `UPDATE ... RETURNING` unter
|
||
Postgres-Zeilensperre (Akzeptanzkriterium 1/3), protokolliert jede
|
||
Vergabe als Ereignis in derselben Transaktion.
|
||
- `Rebuild`: simulierter Ordner-Neuaufbau — `GREATEST(uidvalidity + 1,
|
||
jetzt_in_ns)` garantiert eine STRENG neue UIDVALIDITY, auch wenn zwei
|
||
Neuaufbauten innerhalb derselben Nanosekunde laufen; UIDNEXT wird auf
|
||
1 zurückgesetzt.
|
||
- `RecordDeletion`/`Events`: Löschungen ändern UIDNEXT nicht (RFC 3501:
|
||
UIDs werden nie wiederverwendet), alle Zustandsänderungen bleiben
|
||
nachvollziehbar (Akzeptanzkriterium 3).
|
||
- Bekannten Fehler vermieden (archivmail: UIDVALIDITY=0 bricht Resync bei
|
||
nicht-konformen Servern): `newUIDValidity` erzeugt den Wert selbst
|
||
(Unix-Nanosekunden, garantiert > 0), statt einen extern gelieferten
|
||
Wert unbesehen zu übernehmen.
|
||
- Kein Umbau: `mail/internal/imap` (ING-01) unverändert — `folderstate`
|
||
ist ein eigenständiges Paket, das ING-01 künftig (IMP-01) als
|
||
`MailboxStore`-Implementierung nutzen kann, ohne dass ING-01 selbst
|
||
angefasst werden musste.
|
||
|
||
## Prüfungen
|
||
|
||
| # | Prüfung | Ergebnis |
|
||
|---|---|---|
|
||
| 1 | Automatisierter Test für UIDVALIDITY-Änderung bei simuliertem Ordner-Neuaufbau | **bestanden** – `TestRebuild_ChangesUIDValidityOnSimulatedFolderRebuild`: Ordner angelegt, UID vergeben, `Rebuild` aufgerufen — UIDVALIDITY real geändert, UIDNEXT real auf 1 zurückgesetzt, `rebuilt`-Ereignis real protokolliert |
|
||
| 2 | Nebenläufigkeitstest: zwei Sessions auf demselben Ordner ohne Inkonsistenz | **bestanden** – `TestNextUID_ConcurrentSessionsOnSameFolderNoInconsistency`: 20 reale gleichzeitige `NextUID`-Aufrufe auf demselben Ordner, alle 20 UIDs real eindeutig, keine Dopplung |
|
||
| 3 | Test für UIDNEXT-Monotonie über viele Einfüge-/Löschzyklen | **bestanden** – `TestNextUID_MonotonicAcrossManyInsertDeleteCycles`: 200 Zyklen, jede zweite Nachricht real "gelöscht" — UIDNEXT bleibt real strikt monoton steigend, Löschungen beeinflussen die Vergabe nicht |
|
||
|
||
## Build/Test-Ergebnis (192.168.1.131)
|
||
|
||
```
|
||
go build ./... -> clean
|
||
go vet ./... -> clean
|
||
golangci-lint run ./... -> 0 issues
|
||
TEST_TENANT_DSN=... go test ./internal/folderstate/... -v -> 3/3 bestanden
|
||
TEST_TENANT_DSN=... TEST_MANTICORE_URL=... go test ./... -p 1
|
||
-> alle 13 Pakete bestanden, keine Regression
|
||
```
|
||
|
||
## Gesamtergebnis
|
||
|
||
**Bestanden.** Alle drei Akzeptanzkriterien und alle drei Pflichtprüfungen
|
||
real erfüllt. Entsperrt IMP-01 (gemeinsam mit ING-01, bereits Fertig) und
|
||
ING-10.
|