feat(resource-value-verification): add scheduler resval trace log (task 4.1)

One TRACE (tlog_debug3) line in xce_core_push_events()'s RESVALS_DELTA case,
logging host/resource/value in a fixed format ("resval applied host=...
resource=... value=..."), immediately after the value is written to the
worker's live state. Debug-level only, no control-flow change.

Explicit svalue/fvalue branching (round-2 fix after review) - never reads a
Value_u_t union member without confirming .which matches first, since
Value_u_bvalue (boolean resources) is reachable at this path in production
and would otherwise be misread as a garbage float.

Live-confirmed against a real deployment at -vvv. Also surfaced (but did not
fix, out of boundary) a pre-existing double-free crash on a resource's
second periodic report - logged as bug-1572.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
Rongsong Shen 2026-08-18 01:49:25 +00:00
parent bc1380017e
commit e68444f1e9
Signed by: rshen
SSH key fingerprint: SHA256:8Vf2pZ3h6rJa7EhGK+WaAQ9Mta/apZvteW6g9U/WKKk
2 changed files with 38 additions and 1 deletions

View file

@ -784,6 +784,41 @@ int xce_core_push_events(xce_sched_core_t* core, xce_core_event_t* events,
}
zarray_put(&(w->resvals), res->idx, rv->val);
/* resource-value-verification spec (task 4.1): the only
* place the live scheduler daemon observes and applies a
* resupdate-injected (or real) resource value -- fixed,
* greppable format, host/resource/value fields explicitly
* labeled, so task 6.3's log-tail check can match on
* "resval applied host=<H> resource=<R> value=<V>"
* without depending on any other text in this line.
* Debug/trace level only (tlog_debug3 via TRACE) -- no
* control-flow change, fires on every applied delta.
*
* bug-1573 fix (round-2 remediation): Value_u_which has 7
* tags (ivalue32/uvalue32/ivalue64/uvalue64/svalue/fvalue/
* bvalue -- controller.capnp.h) and Value_u_bvalue is a real,
* reachable tag at this exact path (worker.c's
* mark_host_res() sets it for any XCE_VAL_BOOLEAN resource,
* routed through the same update_val_res()/resupdate RPC).
* Round-1 wrongly treated "not svalue" as "must be fvalue"
* and read the wrong union member for bvalue. Only check
* .u.fvalue once .which is confirmed Value_u_fvalue, mirroring
* core_apply_worker_resvals()'s (this file, ~360 lines above)
* established convention for this same ambiguity: this
* feature's resource set is entirely fvalue/svalue today
* (resval_typeresolve.c), so other tags are silently skipped
* here rather than guessed at. */
if ((rv->val != NULL) && (rv->val->which == Value_u_svalue)) {
TRACE("resval applied host=%s resource=%s value=%s",
w->name ? w->name : "(null)", res->name,
rv->val->u.svalue ? rv->val->u.svalue : "(null)");
} else if ((rv->val != NULL)
&& (rv->val->which == Value_u_fvalue)) {
TRACE("resval applied host=%s resource=%s value=%f",
w->name ? w->name : "(null)", res->name,
rv->val->u.fvalue);
}
}
break;
}