From 75edb7a329bf7e45bc24c8298329a896f3404ed4 Mon Sep 17 00:00:00 2001 From: Rongsong Shen Date: Sat, 22 Aug 2026 09:50:28 +0000 Subject: [PATCH] chore(wolf): checkpoint buglog.json (1003 bugs) --- .wolf/buglog.json | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/.wolf/buglog.json b/.wolf/buglog.json index abf5c200..c1da3b1a 100644 --- a/.wolf/buglog.json +++ b/.wolf/buglog.json @@ -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" } ] }