docs: log bug-1445 for job-array-single-wal-record's first-boot promotion gap

Root cause and reproduction path were already documented inline in
tasks.md task 7.2's Implementation Notes but never had a standalone
buglog entry. Cross-referenced from spec.json's known_limitations.

Not fixed -- suggested shape captured in the bug entry: a small,
single-call-site ha.c ordering fix (move the first promotion-gate
evaluation to run after the first replay_wal(), or have that one gate
call treat "not yet replayed" as non-promotable), not a new Kiro spec.
This commit is contained in:
Rongsong Shen 2026-07-17 10:10:16 +00:00
parent fb701c24a1
commit 5ddc20f359
2 changed files with 26 additions and 1 deletions

View file

@ -24,7 +24,7 @@
"decision": "GO",
"validated_at": "2026-07-17T09:47:00Z",
"known_limitations": [
"First-boot promotion-ordering gap (documented in tasks.md task 7.2's Implementation Notes): a node's very first promotion evaluation in a fresh process runs before that node's own first persist_recover()/replay_wal() call, so the Live Apply Resource Fence is invisible to that one specific check. Every promotion evaluation after a process's first one is protected. Out of this spec's persist.c-only boundary; flagged for a dedicated ha.c follow-up, not tracked as a numbered bug."
"bug-1445: first-boot promotion-ordering gap -- a node's very first promotion evaluation in a fresh process runs before that node's own first persist_recover()/replay_wal() call, so the Live Apply Resource Fence is invisible to that one specific check. Every promotion evaluation after a process's first one is protected. Out of this spec's persist.c-only boundary; tracked in .wolf/buglog.json, not fixed in this spec."
],
"prior_decision": {
"decision": "GO",