Samenwerken: log-compactie van de op-log (Fase 0.5, §5.2 vervolg)

brenno commented

2026-07-31 07:43:23 +00:00

Owner

Vervolg op #1005 (snapshot-herbaselijning). Dat issue maakte bijkomen snel — een deelnemer start vanaf de laatste snapshot en leest alleen de recente records — maar liet de oude op-records staan, zodat de sidecar-op-log onbegrensd blijft groeien bij een lange sessie. Deze issue ruimt die op.

Waarom apart. Compactie was in #1005 bewust als optioneel aangemerkt en heeft twee dingen nodig die #1005 niet toevoegde:

Een WebDAV DELETE-capaciteit. WebdavService kent nu alleen list/download/upload/probe en de store kent geen delete. Records verwijderen is een nieuwe, data-muterende uitgaande operatie op de opslag van de gebruiker — die hoort langs de security-architect (kan het per ongeluk het verkeerde wissen? faalt het dicht?).
Strand-recovery. Als de autoriteit records ≤ snapshot-seq wist, kan een deelnemer die net een oudere snapshot las óf traag inhaalt, een blijvend gat in de reeks raken en vastlopen (de transport wacht op een seq die weg is). De veilige oplossing: een deelnemer die een niet-vulbaar gat detecteert leest de laatste snapshot opnieuw en springt vooruit (versie + seq + deck). Dat maakt compactie race-veilig.

Wat er moet.

CollabLogStore een delete(seq) geven; WebdavCollabLogStore implementeert het met een WebDAV DELETE; WebdavService krijgt de DELETE-methode (met NetGuard/retry zoals de rest).
De autoriteit ruimt na een herbaselijning de records ≤ de nieuwe snapshot-seq op (of met een veiligheidsmarge).
Strand-recovery in de transport/coördinator: bij een blijvend gat de laatste snapshot herlezen en de sessie + transport vooruit zetten.

Beslispunten. Direct wissen tot de snapshot-seq, of een marge aanhouden? Hoe onderscheidt de transport een blijvend gat (compactie) van een nog-niet-geüpload record (transient)? Voorstel: een gat is blijvend als er een nieuwere snapshot bestaat met een versie boven de huidige.

Raakt webdav_service.dart (nieuwe uitgaande operatie → security-architect), de store, de transport en de coördinator. Raakt het .md niet (P2).

Vervolg op #1005 (snapshot-herbaselijning). Dat issue maakte bijkomen snel — een deelnemer start vanaf de laatste snapshot en leest alleen de recente records — maar liet de oude op-records **staan**, zodat de sidecar-op-log onbegrensd blijft groeien bij een lange sessie. Deze issue ruimt die op. **Waarom apart.** Compactie was in #1005 bewust als optioneel aangemerkt en heeft twee dingen nodig die #1005 niet toevoegde: 1. **Een WebDAV DELETE-capaciteit.** `WebdavService` kent nu alleen list/download/upload/probe en de store kent geen delete. Records verwijderen is een nieuwe, data-muterende uitgaande operatie op de opslag van de gebruiker — die hoort langs de security-architect (kan het per ongeluk het verkeerde wissen? faalt het dicht?). 2. **Strand-recovery.** Als de autoriteit records ≤ snapshot-seq wist, kan een deelnemer die net een oudere snapshot las óf traag inhaalt, een blijvend gat in de reeks raken en vastlopen (de transport wacht op een seq die weg is). De veilige oplossing: een deelnemer die een niet-vulbaar gat detecteert leest de laatste snapshot opnieuw en springt vooruit (versie + seq + deck). Dat maakt compactie race-veilig. **Wat er moet.** 1. `CollabLogStore` een `delete(seq)` geven; `WebdavCollabLogStore` implementeert het met een WebDAV DELETE; `WebdavService` krijgt de DELETE-methode (met NetGuard/retry zoals de rest). 2. De autoriteit ruimt na een herbaselijning de records ≤ de nieuwe snapshot-seq op (of met een veiligheidsmarge). 3. Strand-recovery in de transport/coördinator: bij een blijvend gat de laatste snapshot herlezen en de sessie + transport vooruit zetten. **Beslispunten.** Direct wissen tot de snapshot-seq, of een marge aanhouden? Hoe onderscheidt de transport een blijvend gat (compactie) van een nog-niet-geüpload record (transient)? Voorstel: een gat is blijvend als er een nieuwere snapshot bestaat met een versie boven de huidige. Raakt `webdav_service.dart` (nieuwe uitgaande operatie → security-architect), de store, de transport en de coördinator. Raakt het .md niet (P2).

brenno added the

accepted

enhancement

labels

2026-07-31 07:43:23 +00:00

brenno referenced this issue from a commit

2026-07-31 08:01:53 +00:00

docs(collab): document §5.2 re-baselining and the deferred compaction (#1005)

brenno referenced this issue

2026-07-31 08:06:02 +00:00

feat(collab): snapshot-herbaselijning op een niet-nul versie (§5.2, #1005) #1008

brenno referenced this issue

2026-07-31 08:06:41 +00:00

Samenwerken: snapshot-herbaselijning op een niet-nul versie (Fase 0.5, §5.2) #1005

brenno added the

in-progress

label

2026-07-31 08:11:10 +00:00

brenno commented

2026-07-31 08:11:11 +00:00

Author

Owner

Opgepakt. Tak: collab/log-compaction. Bouwt voort op #1005 (de snapshot-seq). Ontwerpkeuzes op de twee beslispunten: (1) compactie houdt een marge aan — na een herbaselijning worden records ≤ de vórige snapshot-seq gewist (dus altijd minstens één herbaselijn-interval bewaard), met strand-recovery als vangnet; (2) een gat geldt als blijvend zodra de laatste snapshot een versie boven de eigen sessie-versie draagt — daarop herbaselijnt de deelnemer zichzelf (leest de snapshot opnieuw, springt sessie+transport vooruit). Reikwijdte: webdav_service.dart (nieuwe DELETE, langs NetGuard/retry → security-architect), collab_log_store.dart (delete(seq)), webdav_async_transport.dart + collab_session.dart (vooruitspringen), handover_coordinator.dart (compactie + strand-detectie). Fail-safe: een mislukte DELETE laat het record staan (onschadelijk). Raakt .md niet (P2).

brenno referenced this issue from a commit

2026-07-31 08:54:36 +00:00

feat(collab): a contained WebDAV DELETE for log compaction (#1007)

brenno referenced this issue from a commit

2026-07-31 08:54:36 +00:00

feat(collab): forward-only session/transport jumps for strand-recovery (#1007)

brenno referenced this issue from a commit

2026-07-31 08:54:36 +00:00

feat(collab): authority log compaction + strand-recovery (#1007)

brenno referenced this issue from a commit

2026-07-31 08:54:36 +00:00

docs(collab): document log compaction and its DELETE capability (#1007)

brenno referenced this issue from a pull request that will close it,

2026-07-31 08:55:06 +00:00

feat(collab): log-compactie van de op-log (§5.2, #1007) #1009

brenno closed this issue

2026-07-31 08:55:20 +00:00

brenno referenced this issue from a commit

2026-07-31 08:55:21 +00:00

Merge pull request 'feat(collab): log-compactie van de op-log (§5.2, #1007)' (#1009) from collab/log-compaction into main

brenno removed the

in-progress

label

2026-07-31 08:55:48 +00:00

brenno commented

2026-07-31 08:55:49 +00:00

Author

Owner

Gebouwd en gemergd in #1009 (main a484b53d). De op-log wordt nu opgeruimd: de autoriteit wist de records die de vorige duurzame basislijn al omvat (één interval marge), het verwijdervenster schuift pas op ná een bevestigd-duurzame snapshot (zodat niemand strandt), en de deletes lopen losgekoppeld van de poll-lus (een trage server kan de heartbeat niet vertragen). Wie tóch te ver achterloopt herbaselijnt zichzelf vanaf de laatste snapshot — alleen vooruit, fail-closed. De WebDAV-client kreeg hiervoor zijn eerste verwijderende operatie; die raakt uitsluitend genummerde recordbestanden, langs dezelfde gepinde, redirect-vrije weg als upload.

Ontworpen na een security-architect-ontwerpreview (zeven eisen, alle hard ingebouwd), daarna een security- en een bewaker-diffreview. De diffreview ving één echte tekortkoming — compactie op het kritieke pad kon een heartbeat vertragen en spontane overdracht uitlokken — die is weggewerkt (losgekoppelde compactie + test).

Daarmee is de Fase-0.5-samenwerkketen rond: #1004 (eigenaarsoverdracht), #1005 (herbaselijning) en #1007 (compactie). De op-log groeit niet langer onbegrensd.

Gebouwd en gemergd in #1009 (main a484b53d). De op-log wordt nu opgeruimd: de autoriteit wist de records die de vorige duurzame basislijn al omvat (één interval marge), het verwijdervenster schuift pas op ná een bevestigd-duurzame snapshot (zodat niemand strandt), en de deletes lopen losgekoppeld van de poll-lus (een trage server kan de heartbeat niet vertragen). Wie tóch te ver achterloopt herbaselijnt zichzelf vanaf de laatste snapshot — alleen vooruit, fail-closed. De WebDAV-client kreeg hiervoor zijn eerste verwijderende operatie; die raakt uitsluitend genummerde recordbestanden, langs dezelfde gepinde, redirect-vrije weg als upload. Ontworpen na een security-architect-ontwerpreview (zeven eisen, alle hard ingebouwd), daarna een security- en een bewaker-diffreview. De diffreview ving één echte tekortkoming — compactie op het kritieke pad kon een heartbeat vertragen en spontane overdracht uitlokken — die is weggewerkt (losgekoppelde compactie + test). Daarmee is de Fase-0.5-samenwerkketen rond: #1004 (eigenaarsoverdracht), #1005 (herbaselijning) en #1007 (compactie). De op-log groeit niet langer onbegrensd.

Rows
Columns

Samenwerken: log-compactie van de op-log (Fase 0.5, §5.2 vervolg) #1007