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

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

Browse source
This commit is contained in:
Rongsong Shen 2026-08-19 04:17:42 +00:00
parent 77eb88c6c9
commit de405d43ec
No known key found for this signature in database
GPG key ID: 9A8F603E5F8A1D8F
1 changed files with 50 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

53
.wolf/buglog.json
View file

@ -16300,7 +16300,7 @@
"error_message": "controller_unit_test: test_conf_trim_keeps_only_n_versions and test_conf_get_saved_tag_no_config (test_config_repl.c) FAIL during an unrelated ASAN controller build/test run (bug-451 fix session)",
"file": "src/controller/testsuite/test_config_repl.c",
"root_cause": "Not investigated -- discovered incidentally while verifying an unrelated fix (bug-451, persist_job_hook_fun's RUSAGE arm). Neither test_config_repl.c nor config_repl.c were touched this session (confirmed via git diff, zero changes). Coincides with a burst of 'persist: flusher fdatasync FAILED (errno=5 Input/output error)' ERROR lines in the same test run, matching this project's well-documented overlayfs sandbox fdatasync artifact class (same family as bug-924, bug-1470, bug-1553) rather than a genuine regression.",
"fix": "NOT FIXED -- out of scope for the bug-451 session that surfaced it. Needs confirmation this is the same overlayfs artifact (re-run on a real fs) before treating it as a real regression in test_config_repl.c's config-version-trim/tag-save logic. Re-observed 2026-08-17 during resource-value-verification task 1.1 (resval_typeresolve extraction) full controller ASAN build/test run: same 2 tests (test_conf_trim_keeps_only_n_versions Expected 2 Was 3, test_conf_get_saved_tag_no_config Expected 0 Was <garbage uint64>), same accompanying persist_flush/flusher fdatasync errno=5 burst. Zero diff in test_config_repl.c/config_repl.c this session either (task 1.1 boundary was testsuite/resval_typeresolve.{c,h}, testsuite/test_resval_typeresolve.c, meson.build only) -- further corroborates the overlayfs sandbox artifact theory over a genuine regression, still unconfirmed on a real fs. Re-observed again 2026-08-17 during resource-value-verification task 2.1 (resupdate fallback + -t flag wiring, GREEN phase): identical 2 tests, identical Expected/Was values, identical fdatasync errno=5 burst, in the same full `/xce-build controller` run that also confirmed resval_typeresolve_unit_test's own Unity summary at 4 Tests 0 Failures (task 2.1's GREEN evidence). Task 2.1's diff was scoped to testsuite/resval_typeresolve.{c,h} and testsuite/test.c only (confirmed via git diff --stat) -- test_config_repl.c/config_repl.c untouched, per this bug's own do-not-chase guidance in tasks.md's Implementation Notes.",
"fix": "NOT FIXED -- out of scope for the bug-451 session that surfaced it. Needs confirmation this is the same overlayfs artifact (re-run on a real fs) before treating it as a real regression in test_config_repl.c's config-version-trim/tag-save logic. Re-observed 2026-08-17 during resource-value-verification task 1.1 (resval_typeresolve extraction) full controller ASAN build/test run: same 2 tests (test_conf_trim_keeps_only_n_versions Expected 2 Was 3, test_conf_get_saved_tag_no_config Expected 0 Was <garbage uint64>), same accompanying persist_flush/flusher fdatasync errno=5 burst. Zero diff in test_config_repl.c/config_repl.c this session either (task 1.1 boundary was testsuite/resval_typeresolve.{c,h}, testsuite/test_resval_typeresolve.c, meson.build only) -- further corroborates the overlayfs sandbox artifact theory over a genuine regression, still unconfirmed on a real fs. Re-observed again 2026-08-17 during resource-value-verification task 2.1 (resupdate fallback + -t flag wiring, GREEN phase): identical 2 tests, identical Expected/Was values, identical fdatasync errno=5 burst, in the same full `/xce-build controller` run that also confirmed resval_typeresolve_unit_test's own Unity summary at 4 Tests 0 Failures (task 2.1's GREEN evidence). Task 2.1's diff was scoped to testsuite/resval_typeresolve.{c,h} and testsuite/test.c only (confirmed via git diff --stat) -- test_config_repl.c/config_repl.c untouched, per this bug's own do-not-chase guidance in tasks.md's Implementation Notes.\n\nRe-observed a 5th time 2026-08-18 during a full `nix develop ./src --command bash src/tools/xce-build.sh all asan build-asan --incremental` verification run on the scheduler-framework branch (post bug-1584/1585 scheduler fixes). Identical signature: same 2 tests, same Expected/Was values (test_conf_trim_keeps_only_n_versions Expected 2 Was 3; test_conf_get_saved_tag_no_config Expected 0 Was large-garbage-uint64), same accompanying persist_flush/flusher fdatasync errno=5 burst. This run recompiled ZERO C source files (ninja reported \"no work to do\" for all C targets -- only the xceadmin custom target/wheel regenerated), so the failure cannot be attributed to any change in this session -- strongest evidence yet that this is purely an environment (overlayfs fdatasync) artifact, not a code regression. Scheduler suite's own single failure in the same run (test_recordstart_symlink_escape_replies_error, bug-1560) is separate and expected.",
"tags": [
"controller",
"testsuite",
@ -16316,8 +16316,8 @@
"bug-1470",
"bug-1553"
],
"occurrences": 4,
"last_seen": "2026-08-17T00:00:00.000Z"
"occurrences": 5,
"last_seen": "2026-08-18T00:00:00.000Z"
},
{
"id": "bug-912",
@ -17481,6 +17481,53 @@
],
"occurrences": 1,
"last_seen": "2026-08-19T03:20:00Z"
},
{
"id": "bug-1590",
"timestamp": "2026-08-19T03:40:00Z",
"error_message": "User-reported: `(sim) info worker all` in the scheduler's interactive REPL shows `resource type: total=0.00 available=0.00` and `resource model: total=0.00 available=0.00` -- but `type`/`model` are STRING-valued resources (e.g. OS type, hardware model name), not numeric, so 0.00 is meaningless. User also notes boolean-typed resources exist and asked to verify resource-value type-correct formatting broadly, across both REPL output and log lines, not just this one command.",
"file": "src/scheduler/src/repl_info.c (repl_info_worker_one ~287-335, repl_info_resource_one ~410-496); src/scheduler/src/core_events.c (~838-861, TRACE 'resval applied'); src/controller/worker.c (~107-119); src/controller/dataex.c (~86-90)",
"root_cause": "CONFIRMED via source read across the whole stack (C scheduler/controller/worker + Go apiserver/xcecli), several distinct severities under one theme -- 'resource values are not type-dispatched when formatted for display/log, several call sites assume every resource is numeric (Value_u_fvalue)':\n\n(1) MOST SEVERE, matches the exact user report -- `repl_info_worker_one()` (repl_info.c:329-334): `avail = (avail_v->which == Value_u_fvalue) ? avail_v->u.fvalue : 0.0;` then unconditionally `fprintf(..., \"total=%.2f available=%.2f\", ...)` -- ANY resource whose wire value is Value_u_svalue (string, e.g. `type`/`model`) or Value_u_bvalue (boolean) silently renders as `0.00`, indistinguishable from a genuinely-zero numeric resource. Comment at line 324-328 references bug-1568 (a DIFFERENT, already-fixed bug about comparing against the wrong enum) but bug-1568's fix never added string/bool handling -- it only made the numeric case correct.\n(2) Same defect, `repl_info_resource_one()` (repl_info.c:436-444, `info resource <name>`): the total/available aggregation loop only accumulates when `->which == Value_u_fvalue` (correctly guarded, no UB) -- but silently EXCLUDES string/bool resources from the sum entirely, so `info resource type`/`info resource model` would also show `total=0.00 available=0.00` despite `valtype=string` being correctly labeled two lines below it (line 489-495) -- an internally inconsistent-looking display (correct type label, wrong/misleading value).\n(3) Related, narrower gap in scheduler logging -- `core_events.c`'s bug-1573 fix (~838-861, the 'resval applied host=... resource=... value=...' TRACE line) DOES correctly branch Value_u_svalue -> '%s' vs Value_u_fvalue -> '%f', but its own comment self-documents that Value_u_bvalue (boolean) is 'silently skipped here rather than guessed at' -- confirmed still true as of this reading: no case handles Value_u_bvalue, so a boolean resource update produces NO trace line at all (silent omission, not a wrong value, but incomplete visibility for exactly the resource kind the user flagged).\n(4) Minor/lower severity, controller-side -- `worker.c` (~107-119) has an `else` branch for non-fvalue that logs `which=%d (non-numeric)` (informative about the presence of a non-numeric update, but never decodes/prints the actual string or boolean value); `dataex.c` (~86-90) has NO else branch at all -- silently skips the TRACE entirely for any non-fvalue resource, weakest visibility of the four sites but least user-facing (debug-level TRACE only).\n\nPOSITIVE finding, scoped this from being a systemic whole-stack issue: the Go apiserver's `cNameValToWorkerResval()` (`src/frontend/apiserver/backend/convert.go:325-370`) is a CORRECT, COMPLETE reference implementation -- it switches on all 7 `Value_u_which` wire tags (ivalue32/ivalue64/uvalue32/uvalue64/fvalue all -> NUMERIC/`NumericValue`, svalue -> STRING/`StringValue`, bvalue -> BOOLEAN/`BooleanValue`, matching `models.ResourceDistributionInfo`'s already-correctly-typed fields, `src/frontend/apiserver/models/resources.go:118-126`), plus a `default:` WARN log for any unrecognized tag. `src/frontend/xcecli/models/resource.go`'s `ResourceValue.UnmarshalJSON()` (client-side) also correctly handles string/bool/numeric JSON values. So the production REST API (apiserver) and `xcecli` CLI resource-value display path are NOT affected -- this bug is confined to the scheduler's own C-side simulation-debugging REPL (`repl_info.c`, the user-facing symptom) and a handful of C-side TRACE/debug log call sites in the scheduler/controller (lower severity, debug-visibility-only gaps).",
"fix": "NOT YET FIXED -- logged and verified per user instruction ('log a bug for this' + 'verify ... formatted as the correct type ... both log/output'), no code changes made yet. When picked up, the fix should generalize repl_info.c's two call sites to switch on `xce_val_t.which` (mirroring convert.go's `cNameValToWorkerResval()` as the reference pattern already proven correct in this codebase) and format accordingly: numeric tags (ivalue32/uvalue32/ivalue64/uvalue64/fvalue) as a number, Value_u_svalue as the raw string, Value_u_bvalue as true/false -- for both the per-resource `total=.../available=...` display (repl_info_worker_one) and the aggregated total across workers (repl_info_resource_one, where 'total'/'available' arithmetic is inherently meaningless for string-valued resources and should probably just show the value directly, e.g. from the first worker holding it, rather than attempting a sum -- needs a design decision, not just a mechanical formatting fix). Also worth closing core_events.c's self-documented boolean-TRACE gap (item 3 above) as a small follow-up while in the area, and deciding whether worker.c/dataex.c's non-numeric TRACE lines (items 4) are worth the same treatment for debug completeness (lowest priority of the four).",
"tags": [
"scheduler",
"repl",
"resource-value",
"type-dispatch",
"display-bug",
"logging",
"open",
"not-yet-fixed"
],
"related_bugs": [
"bug-1568",
"bug-1573"
],
"occurrences": 1,
"last_seen": "2026-08-19T03:40:00Z"
},
{
"id": "bug-1591",
"timestamp": "2026-08-19T03:45:00Z",
"error_message": "User-reported: `(sim) info queue all` in the scheduler's interactive REPL prints raw packed jobids instead of the human-readable form, e.g. `[sim] queued job: jobid=4645085138445664257 priority=0` instead of the 'cluster-apiserver-timestamp-sequence' form (e.g. '3-1-1755590313-976') already used elsewhere in this codebase (bug-1588 fixed the same class of issue in src/controller/job.c's TRACE lines).",
"file": "src/scheduler/src/repl_info.c (queued job: ~230, assigned job: ~356), src/scheduler/src/repl_break.c (~665), src/scheduler/src/sim_loop.c (~379,383,387), src/scheduler/src/sim_verify.c (~293,325,335,346,373,380,389), src/scheduler/src/driver.c (~652), src/scheduler/src/core_events.c (~872,907,979), src/scheduler/src/recording_session.c (~173) -- full raw-jobid-print inventory for the scheduler tree, not yet fixed",
"root_cause": "Same class as bug-1588 (already fixed for src/controller/job.c): fmt_jobid()/fmt_jobid_ex() (src/lib/utils.c, declared src/include/utils.h:132-133) is the established human-readable jobid formatter already used elsewhere in this exact scheduler tree -- scheduler.c, handler.c, plugins/limit.c, plugins/fcfs.c, and even repl_info.c ITSELF at other call sites (e.g. line 119/143/184, per bug-1588's original grep) already call it correctly. The two sites the user's `info queue all` output actually exercises -- repl_info.c's 'queued job: jobid=%llu' (~230, the queue-dump command, `info queue <name>|all`) and its sibling 'assigned job: jobid=%llu' (~356, inside repl_info_worker_one, `info worker <name>|all`) -- were simply never converted, the same oversight bug-1588 already found and fixed in job.c. A broader grep of src/scheduler/src/ for the raw `jobid=%llu`/`jobid: %llu` pattern (see `file` field above) found ~15 more sites across repl_break.c (breakpoint-hit message), sim_loop.c/sim_verify.c (batch --sim DISPATCH/PEND/PREEMPT decision output and --sim-verify divergence reports), driver.c/core_events.c/recording_session.c (WARN/ERROR log lines for unknown-jobid and preemption-not-yet-implemented conditions) -- all likely candidates for the same fix, not yet individually confirmed to be in-scope (some may be deliberately terse WARN/ERROR paths where the raw id is acceptable; needs a per-site judgment call when this is picked up, not a blanket mechanical replace).",
"fix": "NOT YET FIXED -- logged per user instruction, no code changes made. When picked up: apply the exact bug-1588 pattern (`char jobidStr[64]; fmt_jobid(jobidStr, sizeof(jobidStr), <jobid>);` then `%s` in the format string) to repl_info.c's two REPL-output sites first (highest user-visible priority, matches the reported symptom exactly), then triage the remaining ~15 sites in the `file` list above individually -- the REPL/--sim/--sim-verify user-facing output sites (sim_loop.c, sim_verify.c, repl_break.c) are worth doing for consistency with repl_info.c's other already-converted commands; the WARN/ERROR internal-diagnostic sites (driver.c, core_events.c, recording_session.c) are lower priority since they're not routinely user-facing, but should be checked for consistency while in the area.",
"tags": [
"scheduler",
"repl",
"jobid",
"human-readable",
"logging",
"ux",
"open",
"not-yet-fixed"
],
"related_bugs": [
"bug-1588"
],
"occurrences": 1,
"last_seen": "2026-08-19T03:45:00Z"
}
]
}