---
id: "bug-1622"
status: "fixed"
status_updated: "2026-09-24"
status_note: ""
component: "scheduler"
severity: "unknown"
timestamp: "2026-08-22T09:40:00Z"
last_seen: "2026-09-19T09:00:00Z"
occurrences: 1
files: ["src/scheduler/testsuite/test_sim_round_boundary_reconciliation.c"]
tags: ["scheduler", "test", "resource.c", "get_resvals", "return-convention", "scheduler-sim-decision-parity"]
related: []
legacy: true
---

# bug-1622: TEST_ASSERT_EQUAL_INT(0, rc) failed: Expected 0 Was 1, in test_sim_round_boundary_reconciliation.c…

## Description
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)

## Environment
_Not recorded (migrated from buglog.json)._

## Reproduction
_Not recorded (migrated from buglog.json)._

## 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).

## Verification
_Not recorded (migrated from buglog.json)._

## References
_Not recorded (migrated from buglog.json)._