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:
parent
fb701c24a1
commit
5ddc20f359
2 changed files with 26 additions and 1 deletions
|
|
@ -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",
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue