chore(buglog): harness batch fixed (da1a663f): bug-1574/1702/1703/1705/1707-1710/1712/1777/1793/1796/1797

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

.wolf/bugs/bug-1777.md

@@ -1,16 +1,17 @@
 ---
 id: "bug-1777"
-status: "open"
-status_updated: "2026-09-24"
-status_note: "xce_test workerlist MaxSwap ignores hosts.yaml override"
+status: "fixed"
+status_updated: "2026-09-28"
+status_note: ""
 component: "controller"
 severity: "unknown"
 timestamp: "2026-09-06T21:10:00Z"
 last_seen: "2026-09-19T09:00:00Z"
 occurrences: 1
-files: ["src/controller/testsuite/test.c"]
+files: ["src/harness/test.c", "src/harness/joblist_display.c"]
 tags: ["controller", "worker", "resource", "maxswap", "workerlist", "config-override", "deferred"]
 related: ["bug-1554"]
+fix_commits: ["da1a663f"]
 legacy: true
 ---
 
@@ -29,10 +30,12 @@ _Not recorded (migrated from buglog.json)._
 CONFIRMED via code trace (not yet reproduced against a live pc13v/replay artifact -- none existed on disk at investigation time). xce_worker_t carries two separate copies of a host-attrs-style resource: attrs->maxswap (hostattrs_t, written ONLY by xcecd.c's init_host_attrs() at join time -- rejoin_worker(), worker.c:440, just re-copies the same join-time value) and resvals[idx("maxswap")] (resmgr-indexed zarray, seeded from attrs->maxswap by add_hostattrs_resvals() at apply_join_state() start, worker.c, then OVERWRITTEN by mark_host_res()/update_val_res() if a hosts.yaml resource override exists for that host, worker.c:79 `array = &(w->host.resvals)`). cmd_workerlist() (test.c:1478) reads attrs->maxswap directly -- structurally incapable of ever reflecting a config override, since nothing writes an override back into attrs. The scheduler-facing path (collect_resvals_workers() -> resvals_to_sched -> xcesched_push_workers(), dataex.c/sched.c) reads resvals, which DOES pick up the override. So whenever a maxswap override is configured, the scheduler correctly uses it (and a replay/snapshot reflects it) while xce_test workerlist permanently shows the stale join-time value regardless of timing/staleness -- not a caching/race artifact, a structural gap. The Go apiserver/xcecli path (convert.go) also just casts attrs.maxswap with no override-awareness, and xcecli's hosts.yaml model doesn't even expose a MaxSwap column today.
 
 ## Fix
-NOT FIXED -- user explicitly deferred (2026-09-06) to prioritize bug-1554 (real swap/tmp hardware detection, now fixed) and the assigned-jobs slot-count display improvement first. Two candidate fix directions discussed: (a) make cmd_workerlist()/the Go apiserver path read the effective resmgr/resvals value instead of attrs directly, or (b) make mark_host_res() write the override back into attrs too, so every attrs consumer (maxcpus/maxmem/maxswap/maxtmp alike) stays in sync at the source -- (b) was the recommended direction since it fixes the whole class rather than patching each display path individually, but neither is implemented yet.
+Direction (a): workerlist (table and --json) shows maxmem/maxswap/maxtmp from the worker's effective resource values, which the workerlist reply already carries in resvals_to_sched (collect_resvals_workers(), controller/dataex.c) and which include a hosts.yaml override, falling back to the join-time attrs when a value is absent or not numeric (worker_effective_attr(), src/harness/joblist_display.c). Harness only; the Go apiserver's worker view is not changed here.
 
 ## Verification
-_Not recorded (migrated from buglog.json)._
+- Test: test_effective_attr_prefers_resval and test_effective_attr_falls_back_to_join_value in src/harness/testsuite/test_joblist_display.c; new function, the old code read attrs->maxswap directly
+- Suites: harness 6/6 (asan): harness_unit_test 141/0, cmdutil 14/0, resval_typeresolve 7/0, joblist_display 22/0, join_worker_args 7/0, listrow_json 12/0
+- Live: n/a; xce_test is a client tool and every case above runs without a controller
 
 ## References
 - Related: bug-1554