lei.chen/myxce
1
0
Fork 1
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

chore(wolf): checkpoint buglog.json (1003 bugs)

Browse source
This commit is contained in:
Rongsong Shen 2026-08-22 09:50:28 +00:00
parent 0c237f601a
commit 75edb7a329
No known key found for this signature in database
GPG key ID: 5BCDAAE0123E9FE2
1 changed files with 19 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

19
.wolf/buglog.json
View file

@ -18190,6 +18190,25 @@
"related_bugs": [],
"occurrences": 1,
"last_seen": "2026-08-22T08:12:00Z"
},
{
"id": "bug-1622",
"timestamp": "2026-08-22T09:40:00Z",
"error_message": "TEST_ASSERT_EQUAL_INT(0, rc) failed: Expected 0 Was 1, in test_sim_round_boundary_reconciliation.c calling get_resvals(&(w->resInUse), 1, &residx, got)",
"file": "src/scheduler/testsuite/test_sim_round_boundary_reconciliation.c",
"root_cause": "resource.c's get_resvals(zarray_t*, int nres, int*, float*) returns `nres` on success (not 0) -- confirmed by reading its body (resource.c:17-51, `return nres;` at the end). Wrongly assumed a 0-on-success/negative-on-error convention (like most other functions in this codebase, e.g. put_resvals's own callers use `rc >= 0`), and asserted TEST_ASSERT_EQUAL_INT(0, rc) instead of TEST_ASSERT_EQUAL_INT(1, rc) for a 1-resource query.",
"fix": "Changed the assertion to TEST_ASSERT_EQUAL_INT(1, rc) with an inline comment noting get_resvals() returns nres on success. Not a production bug -- purely a test-authoring mistake caught immediately by the RED/GREEN cycle (this was the FIRST failure seen after restoring the task-3 sim_loop.c wiring, so it briefly looked like the fix hadn't worked before the real root cause -- a test bug, not a reconciliation bug -- was found).",
"tags": [
"scheduler",
"test",
"resource.c",
"get_resvals",
"return-convention",
"scheduler-sim-decision-parity"
],
"related_bugs": [],
"occurrences": 1,
"last_seen": "2026-08-22T09:40:00Z"
}
]
}