From 5ddc20f35941e7b397eeb1bfb15d1e36a8901602 Mon Sep 17 00:00:00 2001 From: Rongsong Shen Date: Fri, 17 Jul 2026 10:10:16 +0000 Subject: [PATCH] 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. --- .../job-array-single-wal-record/spec.json | 2 +- .wolf/buglog.json | 25 +++++++++++++++++++ 2 files changed, 26 insertions(+), 1 deletion(-) diff --git a/.kiro/specs/job-array-single-wal-record/spec.json b/.kiro/specs/job-array-single-wal-record/spec.json index 3a20100e..2c201194 100644 --- a/.kiro/specs/job-array-single-wal-record/spec.json +++ b/.kiro/specs/job-array-single-wal-record/spec.json @@ -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", diff --git a/.wolf/buglog.json b/.wolf/buglog.json index 7141f479..3340f0f8 100644 --- a/.wolf/buglog.json +++ b/.wolf/buglog.json @@ -13307,5 +13307,30 @@ ], "occurrences": 1, "last_seen": "2026-07-16T02:48:18Z" + }, + { + "id": "bug-1445", + "timestamp": "2026-07-17T09:47:00Z", + "error_message": "A node's very first promotion-eligibility evaluation in a fresh process runs before that node's own first persist_recover()/replay_wal() call, so the Live Apply Resource Fence (job-array-single-wal-record tasks 4.1-4.3, extended to boot replay by task 7.2) is invisible to that one specific check. A node that would otherwise correctly fence itself non-promotable on a resource-exhaustion apply failure during its first-ever boot replay can instead pass its first promotion check looking fully eligible, because the fence flag hasn't been set yet at the point that first gate runs.", + "file": "src/controller/ha.c", + "root_cause": "ha.c's promotion-gate eligibility check (ha.c:1303-1408) runs before persist_recover()'s first-ever replay_wal() call (ha.c:1427-1439) on a freshly-started process. Every promotion evaluation AFTER a process's first one is correctly protected (persist_apply_resource_fenced() is threaded into both the periodic fence-release check and the election-time check per task 4.3) -- this is a narrow ordering gap specific to the single very-first evaluation of a brand-new process, discovered and documented (not fixed) during job-array-single-wal-record task 7.2's own review, out of that task's persist.c-only file boundary.", + "fix": "NOT FIXED. Root cause and reproduction path already established in tasks.md (job-array-single-wal-record task 7.2 Implementation Notes) and this buglog is the first standalone tracking entry for it -- previously only documented inline in that spec's notes. Suggested shape (per /kiro-validate-impl discussion 2026-07-17): either move the promotion-gate's first evaluation to run after the first replay_wal() completes, or make that one gate call explicitly treat 'has not replayed yet' as non-promotable until the first replay_wal() sets or clears the fence for real. Small, single-call-site ordering fix in ha.c; suggested as a quick TDD fix (not a full Kiro spec) given the narrow scope, but still needs a real fresh-process-boot test plus a live soak given ha.c's HA-critical status.", + "tags": [ + "job-array-single-wal-record", + "ha.c", + "promotion-gate", + "live-apply-resource-fence", + "boot-replay", + "first-boot", + "persist_recover", + "replay_wal", + "ordering-bug", + "not-fixed" + ], + "related_bugs": [ + "bug-1443" + ], + "occurrences": 1, + "last_seen": "2026-07-17T09:47:00Z" } ]