Rongsong Shen
50d016d905
Rewire replay_wal()'s per-entry apply call from apply_wal_entry() to apply_committed_entry() (task 2.2's shared dispatch seam), so restart replay and the future live commit-advance pump (task 6.1) both produce materialized state deterministically from the committed log. apply_wal_entry() is not retired -- it remains ha.c's live standby catch-up/replicated-apply dispatch, untouched. Documents a real hazard: replay now fires AFTER_EVENT hooks for the full post-checkpoint WAL range on every restart, including entries already applied+notified in a prior process life. Traced and confirmed inert today for both hook consumers (scheduler registers post-boot, apiserver gates notify on a connected endpoint empty at boot); flagged in tasks.md and in-line at the call site for re-verification before tasks 4.1/6.1/6.2/6.3 make this path broadly live. |
||
|---|---|---|
| .. | ||
| settings | ||
| specs | ||
| steering | ||