Rongsong Shen
d26ff8870d
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>
3.8 KiB
| id | status | status_updated | status_note | component | severity | timestamp | last_seen | occurrences | files | tags | related | legacy | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| bug-1515 | fixed | 2026-09-24 | scheduler | unknown | 2026-08-10T20:20:00.000Z | 2026-09-19T09:00:00Z | 1 |
|
|
|
true |
bug-1515: /goal-driven deep re-review of component-failover-adoption requirements.md+design.md found 5…
Description
/goal-driven deep re-review of component-failover-adoption requirements.md+design.md found 5 additional distinct defects after bug-1514's fix, several introduced by bug-1514's own Req 7 fix
Environment
Not recorded (migrated from buglog.json).
Reproduction
Not recorded (migrated from buglog.json).
Root cause
(1) Req 3 AC2's '~6-job grace window' was stated as 'at least 6' (a floor) when 6 is actually the best-case ceiling; the real guaranteed floor is 1-2 depending on decisions-cbuf occupancy at the moment of stall -- direction of the bound was backwards. (2) Citation scheduler.c:1253 for sched_publish_pend_reason was off by 2 (actual line 1251). (3) Cross-cutting: the shared 'check and clear needs_rejoin, then call xcecli_join' pattern (worker/scheduler/apiserver) cleared the flag unconditionally rather than only on xcecli_join's own success -- since xcecli_join is itself XCECLI_FAILOVER_CALL-wrapped and can hit its own retry-budget exhaustion, this could leave a component transport-connected but permanently un-joined with nothing left to retry (no requirement/design text previously covered this). (4) The Req 7 scheduler decision-publish retry loop only checked core.stop in the while-condition (after each attempt), so multiple decisions queued behind a stuck one would each burn a full ~100s budget cycle discovering shutdown was requested, compounding shutdown latency to minutes instead of the claimed ~1-2 min bound. (5) While fixing (3) for apiserver's heartbeat-idle-path, the first draft gated the retry on ApiserverBackendHealth.IsDegraded() -- but that state has its own independent TTL-based auto-clear for circuit-breaker purposes; if the TTL expired before an actual rejoin succeeded, the retry would silently stop, reintroducing the exact starvation bug (3) was fixing. Two unrelated state machines (rejoin-tracking vs request-path circuit-breaker) had been conflated onto one flag.
Fix
(1) Reworded Req 3 AC2 and all design.md/research.md/tasks.md echoes to state the guarantee qualitatively (bounded, occupancy-dependent, resumes with zero loss per Req 7) instead of a wrong fixed number. (2) Fixed the line citation. (3) Added Requirement 2 AC5 (rejoin retry-on-failure, applies to all three components) and updated the shared 'Rejoin callback constraint' section plus all three component sections in design.md and their tasks.md task bullets to clear the flag only on xcecli_join success. (4) Changed the Req 7 retry loop from do/while to while (check core.stop before each attempt, not only after) so only the actively in-flight decision can cost a full budget cycle; queued decisions behind it skip immediately once stop is set. (5) Introduced a dedicated needs_rejoin flag for apiserver's heartbeat path (set on transition, cleared only on join success) fully decoupled from ApiserverBackendHealth's TTL-governed degraded state; updated the sequence diagram, prose, and tasks.md task 4.4 accordingly, plus an explicit note in ApiserverBackendHealth's section warning against this conflation. Also added Req 7 AC6 documenting that the fix does not survive a scheduler process crash/restart (in-memory only, no persistence).
Verification
Not recorded (migrated from buglog.json).
References
- Related: bug-1514