From d9b43c2d2f9d29dc672b7af8f1dca0c7c41ad007 Mon Sep 17 00:00:00 2001 From: Rongsong Shen Date: Thu, 18 Jun 2026 11:21:10 +0000 Subject: [PATCH] chore(ha-commit-durability): mark 5.1 + all phase groups complete (all 18 sub-tasks done) --- .kiro/specs/ha-commit-durability/tasks.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/.kiro/specs/ha-commit-durability/tasks.md b/.kiro/specs/ha-commit-durability/tasks.md index 6720346..1bbe185 100644 --- a/.kiro/specs/ha-commit-durability/tasks.md +++ b/.kiro/specs/ha-commit-durability/tasks.md @@ -4,7 +4,7 @@ > Re-verify HA changes against `raft/raft.tla` and the `src/controller/CLAUDE.md` Protocol Verification Checklist. > Most core tasks edit the same correctness-critical files (`persist.c`, `commit.c`, `ha.c`, `cluster.c`) and are therefore sequential by design; only genuinely file-disjoint analysis is marked `(P)`. -- [ ] 1. Foundation: durability verification seam and deterministic reproduction +- [x] 1. Foundation: durability verification seam and deterministic reproduction - [x] 1.1 Add a configurable flush-cadence override - Parse a `--wal-sync-ms` controller flag (following the existing `--sync-timeout-ms` convention) into the persistence config before persistence starts; default behavior unchanged. - Observable: starting a controller with `--wal-sync-ms ` sets the flush cadence to N; omitting it preserves the current default. @@ -23,7 +23,7 @@ - _Requirements: 3.1, 3.2_ - _Depends: 1.1, 1.2_ -- [ ] 2. Durable commit mechanism (acknowledgment ⇒ majority persistence) +- [x] 2. Durable commit mechanism (acknowledgment ⇒ majority persistence) - [x] 2.1 Introduce durable-LSN tracking via a group-commit flusher - Repurpose the background fsync thread from a timer into a demand-driven flusher: an append signals it; it performs one `fdatasync` over all pending appends, advances a durable-LSN watermark, and wakes the commit evaluation. - Guard against lost wakeups: the signal is level-triggered on the appended-vs-synced gap so an entry is never considered durable before its `fdatasync` (gating item). @@ -50,7 +50,7 @@ - _Boundary: DurableCommit_ - _Depends: 2.1_ -- [ ] 3. Recovery integrity (no silent truncate; durable floor) +- [x] 3. Recovery integrity (no silent truncate; durable floor) - [x] 3.1 Return a recovery integrity verdict and mark a truncated member non-promotable - Make WAL replay distinguish a clean log end from a corruption-stopped end (CRC chain break / mismatch / short read) and surface that verdict; a corruption-truncated recovery is never reported as a clean recovery and sets a member-level "recovery-truncated" flag that the promotion gate (4.3) consumes. - Observable: a unit test injecting a CRC break at the first entry yields a TRUNCATED verdict and sets the non-promotable flag, while an intact log yields CLEAN; an empty first-boot WAL is CLEAN (not corruption). @@ -77,7 +77,7 @@ - _Requirements: 2.3_ - _Boundary: RecoveryIntegrity_ -- [ ] 4. Promotion fence and durable-backed freshness +- [x] 4. Promotion fence and durable-backed freshness - [x] 4.1 (P) Pin the freshness-floor formula and re-verify election safety and liveness - Define the exact reconciliation of the durable-derived freshness floor against the existing in-memory floor — the durable quantity is the durable **last-log index** (WAL tip), not the commit position — then re-check it against `raft/raft.tla` for Leader Completeness AND liveness (no election livelock) plus the Protocol Verification Checklist (gating item; analysis only, no shared source files). - Scope of the raft.tla check: it validates the **election/freshness logic** (the `mlastLogIndex`/`LastTerm` semantics this change touches), which raft.tla models directly. It does NOT validate the *durability* of that floor — raft.tla assumes a durable log (see 5.3). The durability of the WAL-tip derivation is verified by tests (3.4), not by raft.tla. @@ -105,8 +105,8 @@ - _Depends: 4.3, 3.3_ - _Boundary: PromotionFence_ -- [ ] 5. Integration and validation -- [ ] 5.1 Wire durable-majority commit end to end +- [x] 5. Integration and validation +- [x] 5.1 Wire durable-majority commit end to end - Connect the durable-LSN self-count and the commit barrier so the client reply is released only after the entry is durable on a majority; assert liveness (the flusher does not stall heartbeat/election handling). - Observable: an integration test confirms reply-ok only after durable-majority, killing the sole durable contributor mid-commit leaves the acknowledged op present on the survivors, and the full controller suite passes under ASAN. - _Requirements: 1.1, 1.4, 1.5, 1.6, 2.5_