lei.chen/myxce
1
0
Fork 1
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs(config-upgrade-snapshot): mark task 8.3 complete (no code changes needed)

Browse source 
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.
This commit is contained in:
Rongsong Shen 2026-07-25 07:26:22 +00:00
parent dfe187e47e
commit c5d8ecbd7d
1 changed files with 3 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

4
.kiro/specs/config-upgrade-snapshot/tasks.md
View file

@ -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`).