From c5d8ecbd7d90c5cf88ff29596fdf2058238f4283 Mon Sep 17 00:00:00 2001 From: Rongsong Shen Date: Sat, 25 Jul 2026 07:26:22 +0000 Subject: [PATCH] docs(config-upgrade-snapshot): mark task 8.3 complete (no code changes needed) Verified (implementer + independent reviewer) that the 10 fence tests already in test_config_repl.c (tasks 6.1/6.2) fully satisfy task 8.3's bullets and Requirements 3.2/3.3/3.4/4.3/5.5 -- zero-diff task. Task 8.3 of 19. --- .kiro/specs/config-upgrade-snapshot/tasks.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/.kiro/specs/config-upgrade-snapshot/tasks.md b/.kiro/specs/config-upgrade-snapshot/tasks.md index 4092fed0..bb558910 100644 --- a/.kiro/specs/config-upgrade-snapshot/tasks.md +++ b/.kiro/specs/config-upgrade-snapshot/tasks.md @@ -98,7 +98,7 @@ - _Depends: 3_ - _Boundary: Host Restore (test_upgrade_snapshot_restore.c)_ -- [ ] 8.3 (P) Unit-test the activation fence +- [x] 8.3 (P) Unit-test the activation fence - Assert the fence sets on incomplete materialization or a configuration-hash mismatch and clears on successful verification - Assert the request-dispatch gate's allowlist behavior while fenced, and that promotion is refused while fenced - Observable: the new test suite passes, demonstrating fence set/clear transitions and correct gating of both serving and promotion @@ -149,6 +149,8 @@ ## Implementation Notes +- **Task 8.3: no new tests needed** — the 10 tests already in `test_config_repl.c` from tasks 6.1/6.2 fully satisfy both bullets and Requirements 3.2/3.3/3.4/4.3/5.5 (verified independently by implementer and reviewer; zero-diff task). The two "fence sets" tests genuinely toggle different halves of `upgrade_materialization_verify`'s condition (materialized vs. bytes_verified), not duplicates. Retry-trampoline automatic-firing (delaymgr actually running) is untested, matching the exact precedent depth of `config_activate_retry_fn`/`config_schedule_activate_retry` (also untested at that depth anywhere in this codebase) — judged out of scope, not a gap. + - **Task 8.2: no new tests needed** — task 3's `test_upgrade_snapshot_restore.c` already satisfies all 3 bullets and Requirements 1.10/1.11/5.8/7.1 (verified independently by both implementer and reviewer; zero-diff task). Requirement 7.1's full scenario is compositionally covered across two files (`test_upgrade_snapshot_restore.c`'s real-rejoin test + `test_persist_snapshot_entities.c`'s `test_snapent_load_snapshot_restores_hosts_and_queues_end_to_end`'s real checkpoint-decode test), not by one continuous test — judged adequate since `restore_host_state` is a single invocation-site-independent function. design.md's Requirements Traceability table (row 7.1) under-credits this and should eventually be corrected to cite both files, not just `test_upgrade_snapshot_restore.c` — docs-only, not a testing gap. - **Task 6.2 round-1 rejection (real bug, caught by review):** the first implementation wired the fence into both gates + a retry trampoline correctly, but `upgrade_materialization_fence` had no production path that could ever SET it from its zero-initialized default — every setter call site was gated on the fence already being set (closed loop). Fixed with two unconditional call sites: `persist.c`'s `apply_committed_entry` `WAL_CONFIG_MARKER` case now unconditionally calls `upgrade_materialization_verify(c)` right after `persist_checkpoint_marker_triggered` returns (regardless of its rc), and `myapp.c`'s boot sequence unconditionally calls it right after `config_activate_committed` (Req 5.2, crash/restart resume). New cross-module direction: `persist.c` now externs an `ha.c` function (mirrors the existing `persist.c → worker.c` extern pattern, no circular include). Lock-reentrancy re-verified safe (neither call chain touches `apply_pump_lock`).