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>
4.7 KiB
| id | status | status_updated | status_note | component | severity | timestamp | last_seen | occurrences | files | tags | related | legacy | gitea_issue | gitea_synced_status | |||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| bug-1834 | fixed | 2026-09-24 | scheduler | unknown | 2026-09-20T09:35:00Z | 2026-09-20T10:15:00Z | 1 |
|
|
|
true | 61 | fixed |
bug-1834: User-identified design gap (not yet reproduced as a live symptom, code-traced and confirmed): for…
Description
User-identified design gap (not yet reproduced as a live symptom, code-traced and confirmed): for a percent-based limit whose resname is a dynamic/consumable resource (e.g. mem, swap), the limit's CAPACITY is computed as percent * the resource's current LIVE value, not percent * the resource's static total. This means the same limit's enforced cap drifts up and down as unrelated memory pressure on the host changes, rather than staying pinned to a stable fraction of total capacity (e.g. 'this queue may use up to 20% of the host's total memory' should not shrink because some other job is currently using more memory).
Environment
Not recorded (migrated from buglog.json).
Reproduction
Not recorded (migrated from buglog.json).
Root cause
update_limit_res_value() (limit.c:142-165) computes val = get_resvals(array, 1, &(vres->res->idx), &val); val = val * vres->limit->val.val; for any percent!=0 limit -- vres->res is resolved in instantiate_limit() (xcelimit.c:574) via a single key_find(resmgr, limit->val.resname, ...), i.e. exactly the resource named by the limit's OWN resname field. resname today serves two roles that this code conflates: (1) selecting the accounting/consumable resource the limit's virtual resource (vres->vres) is keyed against for usage tracking (correctly mem, since jobs consume mem), and (2) supplying the live base value multiplied by percent to derive capacity (currently ALSO mem, the dynamic worker-reported load index per .kiro/steering/resource-accounting.md -- 'mem is not maxmem... mem is a dynamic load index... refreshed on the worker's regular load-report cadence'). Role (2) should read a static/non-consumable resource instead (maxmem for mem, maxswap for swap) -- both already exist as registered per-host resources (src/configs/resources.yaml:108 maxmem, :112 maxswap, 'self-reported once by the worker at join time and never refreshed' per resource-accounting.md) so no new resource type is needed, only a change to which resource the percent multiplication reads. xce_limit_val_t/xce_limit_config_t (types.h:800-818) have no field today to name this second resource explicitly -- resname is single-purpose in the struct.
Fix
FIXED (2026-09-20). Added xce_vres_t.percent_res (src/include/xce/types.h) -- a resolved xce_resource_t* pointer for the percent-branch capacity read, kept separate from res (which stays the limit's own accounting resource, unchanged) so the two roles are no longer conflated. instantiate_limit() (src/lib/xcelimit.c) resolves it ONCE at instantiation time via a small table-driven static lookup (percent_capacity_resource_map[]: mem->maxmem, swap->maxswap) -- table-driven per user request, so a future dynamic/static pair (e.g. tmp/maxtmp) is a one-line addition. A missing/unregistered counterpart is NOT a hard failure: percent_res stays NULL and update_limit_res_value() (src/scheduler/src/plugins/limit.c) falls back to res, preserving today's behavior for any resource with no known static pair -- this is what keeps every pre-existing percent-limit test passing unchanged (they never register 'maxmem' in their resmgr fixtures, and none of them exercise update_limit_res_value()'s real computation anyway -- its existing white-box harness, test_repl_limit_table.c, stubs get_resvals()/put_resvals() as no-ops). New coverage: 4 unit tests in src/lib/testsuite/test_limit.c proving percent_res resolves to maxmem/maxswap for mem/swap, stays NULL for percent=0, and stays NULL (graceful fallback, not -ENOENT) for a percent-based limit on a resource with no known static counterpart (e.g. ncpus). Extended the shared src/lib/testsuite/test_resmgr_fixture.c/.h with maxmem/swap/maxswap test resources for this. Full lib (314 tests) and scheduler (85 test binaries) suites pass with zero regressions -- confirmed via raw testlog grep for ':FAIL:', not just the meson aggregate summary.
Verification
Not recorded (migrated from buglog.json).
References
- Related: bug-1831, bug-1832
- Gitea: #61