wdgzyjx/myxce
1
0
Fork 0
forked from lei.chen/myxce
Code Pull requests Activity

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

Browse source 
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
Download patch file Download diff file Expand all files Collapse all files

2
.kiro/specs/job-array-single-wal-record/spec.json
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",

25
.wolf/buglog.json
View file

@ -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"
}
]