myxce/.wolf/bugs/bug-1684.md
Rongsong Shen d26ff8870d
feat(buglog): one Markdown record per bug, checked against a record standard
The buglog was one 27K-line JSON file whose fields covered only symptom,
root cause and fix, as free text: 2% of entries named the code version a
bug was found on, 12% the build profile, 36% a way to reproduce, and 58% of
the file was OpenWolf hook auto-detections ("Missing guard clause",
"Function not marked async" on .md files).

- .claude/skills/buglog/bug-record.md: the record standard. Eight
  sections (Summary as the title, Description, Environment, Reproduction;
  Root cause, Fix, Verification, References once fixed), each with the
  content it must contain -- e.g. Environment needs the OS, the libc the
  failing binary loads (from its ELF interpreter: glibc 2.42 in the nix
  shell vs 2.40 on the host), toolchain, build profile and commit.
- .wolf/bugs/<id>.md: 500 records migrated from buglog.json; every field
  verified to round-trip. They carry legacy: true and an explicit "not
  recorded" where the old log had no such field; component derived from
  file paths, severity from keywords (else unknown), fix_commits from
  hashes in status_note/fix that git resolves (91 of 463 fixed).
- .wolf/buglog-archive.json: the 710 hook auto-detections, verbatim.
- .wolf/buglog.json is now an index generated from the records, keeping
  the fields OpenWolf's hooks and `openwolf bug search` read.
- scripts/buglog.py rewritten: new (template + Environment collected from
  the machine and --binary), check, status (refuses a status the record
  doesn't support; fixed needs Root cause, Fix, Verification and
  --commit hashes git resolves), note, recur, set, show, list, triage,
  env, index. 29 unittest cases in scripts/tests/test_buglog.py.
- scripts/git-hooks/pre-commit runs `check --staged`: incomplete staged
  records, a legacy record hand-changed to fixed without the fix-time
  sections, a new record claiming legacy: true, or a stale index refuse
  the commit.
- scripts/gitea-sync.py reads the records: issue body = the record's
  sections plus linked fix commits (origin remote, GITEA_COMMIT_REPO to
  override), and a body hash so an issue's text is refreshed when the
  record changes.
- bug-1866 rewritten to the full standard as the worked example.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-28 03:40:11 +00:00

40 lines
5.1 KiB
Markdown

---
id: "bug-1684"
status: "fixed"
status_updated: "2026-09-24"
status_note: ""
component: "controller"
severity: "unknown"
timestamp: "2026-08-25T00:50:00Z"
last_seen: "2026-09-19T09:00:00Z"
occurrences: 1
files: ["src/controller/ha.c"]
tags: ["controller", "ha", "raft", "election-safety", "persistence", "error-handling"]
related: []
legacy: true
---
# bug-1684: xce-audit-invariants controller audit (dimension: error handling) finding: raft_cb_persist()…
## Description
xce-audit-invariants controller audit (dimension: error handling) finding: raft_cb_persist() (src/controller/ha.c:2257) always returns 0 to the raft library's on_persist callback contract regardless of whether the term/voted_for durability write to disk actually succeeded -- a disk I/O failure (full disk, permission error, transient I/O error) could let a node grant a vote it has no durable record of, opening a split-vote path if that node then restarts and forgets it voted (Election Safety: 'a server grants at most one vote per term' via durably-persisted votedFor).
## Environment
_Not recorded (migrated from buglog.json)._
## Reproduction
_Not recorded (migrated from buglog.json)._
## Root cause
src/lib/raft/raft.c:260-263's raft_on_vote_request Step 7 has an explicit durability-guarantee contract: 'if (s->cbs->on_persist(...) != 0) { /* Persist failed -- deny without updating voted_for */ return RAFT_DENY; }' -- the adapter's on_persist callback (raft_cb_persist) must return non-zero on a genuine persist failure. raft_cb_persist's own doc comment even claimed this contract ('Returns 0 on success, non-zero on error'), but its implementation called ha_persist_term(ha, workdir) and then unconditionally `return 0;` regardless of the outcome. ha_persist_term() itself (ha.c:5174) had a void return with every open()/write()/fsync() failure silently discarded (`if (fd < 0) return; /* best-effort; caller must not rely on this for correctness */`), so the failure was structurally invisible to the caller even before raft_cb_persist's own bug. Compounding: raft_cb_persist mutates ha->voted_for_term/ha->voted_for_name in-memory BEFORE calling ha_persist_term, so even fixing just the return-code propagation would leave the adapter's own in-memory state claiming a vote was cast that the raft library itself denied and never durably recorded -- a second-order inconsistency needing an explicit rollback.
## Fix
FIXED (2026-08-25). ha_persist_term() (ha.c:5174, declared ha.h:1307) relocated from void to int -- returns 0 on success (including the deliberate NULL-workdir test-mode skip) or -errno on a genuine open/write/fsync/rename failure (fsync's own previously-unchecked return value is now checked too). raft_cb_persist() (ha.c:2257) now captures ha_persist_term's return, and on failure: (a) logs a loud ERROR with term/voted_for/rc, (b) rolls back ha->voted_for_term/ha->voted_for_name to their pre-call snapshot (taken under ha->lock before the tentative mutation) so the adapter's in-memory state stays consistent with the raft library's own 'deny without updating voted_for' behavior, (c) returns the negative rc so raft_on_vote_request denies the vote per its own Step 7 contract. ha->term is deliberately NOT rolled back -- confirmed via direct read of raft_on_vote_request's Step 2 (raft.c:191-204) that the raft library itself adopts a higher observed term unconditionally, before and independent of the vote-grant/persist outcome, so the adapter's ha->term correctly mirrors that same unconditional-adoption semantics. Also fixed the adjacent stale doc-comment (src/controller/CLAUDE.md's Protocol Verification Checklist item 1, found by a sibling audit dimension the same session) which incorrectly claimed term+voted_for were written 'atomically under ha->lock' -- term uses a separate atomic store outside the lock.
Test: added 3 tests to testsuite/test_ha_durability.c. (1) test_persist_term_returns_error_on_write_failure -- points workdir at a path whose parent directory doesn't exist (deterministic ENOENT, portable, no permission-bit tricks needed even running as root), asserts ha_persist_term returns <0. (2) test_persist_term_null_workdir_returns_success -- regression guard that the NULL-workdir test-mode skip stays a 0/success return, not folded into the new error path. (3) test_vote_denied_and_state_rolled_back_on_persist_failure -- drives the REAL production path (ha_init_raft wiring raft_cb_persist as the real on_persist callback, then raft_on_vote_request -- the exact function cluster.c's production dispatch calls) against a minimal cluster_t/myconf_t fixture (ha_init_raft(ha, NULL, n) avoids needing a real persist_t, ha->raft_c set directly afterward -- the same test-shim pattern ha.h already documents for raft_cb_become_leader_for_test/raft_cb_become_follower_for_test) with a genuine non-empty candidate name populated so the rollback assertion is meaningful (not trivially satisfied by an already-empty baseline); asserts the vote is RAFT_DENY and ha.voted_for_term/voted_for_name are unchanged from their pre-call baseline.
## Verification
_Not recorded (migrated from buglog.json)._
## References
_Not recorded (migrated from buglog.json)._