replay_wal() now halts logical apply and engages persist_mark_apply_resource_fenced() on a negative apply_committed_entry() return during boot/restart replay, mirroring persist_apply_pump_run()'s existing live-path halt-and-fence behavior (task 4.1). Physical scan bookkeeping (current_lsn, CRC chain) stays unconditional per entry, consistent with persist_recover()'s own established current_lsn/last_applied_lsn divergence precedent. Went through one remediation round: round 1 exercised the wrong ha.c gate (periodic re-alert timer); round 2 corrected the test to drive the real election-time gate (raft_cb_become_leader_with_cluster_for_test()), with teeth independently confirmed via a temporary fence-clear RED/GREEN cycle. Round-2 reviewer APPROVED. Documents a real, NOT-fixed residual gap found during this task: a node's very first-ever promotion evaluation in a fresh process runs before that node's own first persist_recover()/replay_wal() call, so this fence is invisible to that one promotion check (ha.c:1303-1408 gate runs before ha.c:1427-1439's first-boot recovery). Every promotion evaluation after a process's first one is protected. Out of this task's persist.c-only boundary; flagged for a dedicated ha.c follow-up. |
||
|---|---|---|
| .. | ||
| settings | ||
| specs | ||
| steering | ||