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

docs: sync OpenWolf state

Browse source 
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019QxaSzHRB7pmYFp4cVnwkA
This commit is contained in:
Rongsong Shen 2026-08-30 15:32:16 +00:00
parent 5c2c6664e5
commit 1c4a1ba24a
No known key found for this signature in database
GPG key ID: 5BCDAAE0123E9FE2
4 changed files with 88 additions and 36 deletions
Download patch file Download diff file Expand all files Collapse all files

26
.wolf/buglog.json
View file

@ -16201,23 +16201,25 @@
"timestamp": "2026-08-15T22:54:35Z",
"error_message": "test_recordstart_symlink_escape_replies_error (src/scheduler/testsuite/test_admin_request.c:850) FAILED: Expected 'invalid record file name' Was 'permission denied accessing record file'. Surfaced only now because bug-1559's fix made xce-build.sh's scheduler case run the full `meson test --suite scheduler` for the first time -- this test was never reached by the old sched_test-only invocation.",
"file": "src/scheduler/testsuite/test_admin_request.c, src/scheduler/src/recording.c",
"root_cause": "Not yet investigated. Test plants a symlink inside record_dir whose target resolves outside record_dir, then issues a recordStart admin request expecting rejection with error string 'invalid record file name' (the canonical-path containment check). Instead the admin path is returning a 'permission denied accessing record file' error, implying some permission-check code path is being hit and short-circuiting before (or instead of) the containment check in this sandbox environment (uid 1000, non-root) -- ordering between the two checks in recording.c not yet confirmed by direct read. Unrelated to component-failover-adoption / bug-1548/1549/1558/1559 -- discovered purely as a side effect of bug-1559's coverage-gap fix making this test reachable.",
"fix": "NOT FIXED -- out of scope for the component-failover-adoption remediation that surfaced it. Needs its own investigation of recording.c's record-file validation check ordering. NEW NUANCE (2026-08-20, build-time-versioning task 6.1): because xce-build.sh has `set -euo pipefail` and its scheduler case's RUN_TESTS block runs the FULL `meson test --suite scheduler` unconditionally (asan profile only), this one persistently-failing test makes the WHOLE `xce-build.sh scheduler asan ...` invocation exit non-zero EVEN THOUGH `meson compile` (all 430/430 targets) already succeeded and the real xce_scheduler binary was produced correctly -- any downstream script/wrapper that treats a non-zero xce-build.sh exit as \"build failed\" will incorrectly abort/skip real post-build verification (e.g. checking --version output) on the asan profile specifically. src/tools/test-build-version-regression.sh (task 6.1's new regression check) works around this deliberately: it captures xce-build.sh's exit code via `cmd || rc=$?` (NOT a bare unguarded call, which would trigger its own set -e), prints a WARNING distinguishing \"compile succeeded, only the bundled test run failed\" from a genuine build failure, and continues to check the binary/--version output regardless -- the binary-existence check right after is what still catches a REAL compile failure. Root cause of the underlying test failure itself remains unfixed/uninvestigated.\n\nRe-observed a 5th time 2026-08-23 during the scheduler-dispatch-commit feature's final GO/NO-GO release-gate verification run (`xce-build.sh scheduler asan build-asan --incremental`, tree fully committed, zero uncommitted diff in src/scheduler/). meson compile succeeded (467/467 targets, zero compiler errors/warnings-as-errors), xce_scheduler and all testsuite binaries linked cleanly; the bundled `meson test --suite scheduler` run's only failure was this same test (Expected 'invalid record file name' Was 'permission denied accessing record file'), still unrelated to job.c/handler.c dispatch-commit work. Confirmed the feature's own targets separately, both green: `scheduler dispatch commit test` (5 Tests 0 Failures) and `scheduler handlers test` (7 Tests 0 Failures, including the new test_handle_notify_job_dispatch_fail_enqueues_pend case).",
"root_cause": "Not yet investigated. Test plants a symlink inside record_dir whose target resolves outside record_dir, then issues a recordStart admin request expecting rejection with error string 'invalid record file name' (the canonical-path containment check). Instead the admin path is returning a 'permission denied accessing record file' error, implying some permission-check code path is being hit and short-circuiting before (or instead of) the containment check in this sandbox environment (uid 1000, non-root) -- ordering between the two checks in recording.c not yet confirmed by direct read. Unrelated to component-failover-adoption / bug-1548/1549/1558/1559 -- discovered purely as a side effect of bug-1559's coverage-gap fix making this test reachable.\n\n[UPDATE 2026-08-30] ROOT-CAUSED, confirmed by direct code reading and cross-checked against a sibling unit test. sched_validate_record_filename() (recording.c)'s canonical-path containment check (path_is_contained() branch, hit when a pre-existing symlink inside record_dir resolves outside it) deliberately returns -EACCES, not -EINVAL -- -EINVAL is reserved for Step 1's malformed-filename check (bare '/' or '..' in the filename itself, rejected before any filesystem access). This is NOT environment-dependent (not a uid-1000-vs-root permission-check ordering issue as originally suspected) -- test_recording_path_validation.c's own direct unit test for the identical scenario (test_symlink_inside_record_dir_escaping_outside_is_rejected) already asserts TEST_ASSERT_EQUAL_INT(-EACCES, rc) and has always passed. The bug was purely in test_admin_request.c's test_recordstart_symlink_escape_replies_error, which asserted the wrong expected error string (\"invalid record file name\", the -EINVAL string) against production code that has always, correctly, returned -EACCES (\"permission denied accessing record file\") for this exact scenario.",
"fix": "FIXED (2026-08-30). Corrected test_recordstart_symlink_escape_replies_error's expected error string in src/scheduler/testsuite/test_admin_request.c from \"invalid record file name\" to \"permission denied accessing record file\", matching the already-correct, already-independently-verified production behavior. No production code changed -- this was purely a wrong test assertion, not a real product bug (the symlink-escape IS correctly rejected; only the test's expectation of WHICH rejection string was wrong). Verified: full `meson test --suite scheduler` run clean, Ok:55 Fail:0, all 55 test binaries pass including sched_admin_request_test (16/16 cases in test_admin_request.c PASS).",
"tags": [
"scheduler",
"recording",
"symlink",
"test-failure",
"coverage-gap-discovery",
"unresolved",
"xce-build.sh",
"set-e-propagation"
"set-e-propagation",
"fixed",
"test-only-bug",
"not-environment-dependent"
],
"related_bugs": [
"bug-1559"
],
"occurrences": 5,
"last_seen": "2026-08-23T21:53:00Z"
"last_seen": "2026-08-30T08:25:00"
},
{
"id": "bug-1652",
@ -20056,7 +20058,7 @@
"error_message": "PRIORITY: LOW -- display/reporting only, not consumed by any scheduling logic. Split 2026-08-30 from bug-1735 at user request: the 'statistics-only' half of that finding -- resource usage fields with no scheduling relevance, purely for operator-facing job accounting/reporting (bjobs -l/bhist-style views), as opposed to bug-1735's memory+CPU-time core, which is a prerequisite for future scheduling decisions. Worker (collect_job_rusages(), xcecd_cgroups.c) already measures and sends 'memory_swap' and 'tasks_current' per job, but the controller has NO field to receive them at all (xce_host_runusage_t only has cpu_time/mem_usage -- no swap or task-count field exists) -- these two are silently dropped entirely, not just misnamed. Separately, xce_job_runusage_t's peak/efficiency fields (peak_cpu_time, peak_cpu_duration, mem_efficiency, avg_cpu_efficiency, peak_cpu_efficiency) have no computation logic anywhere in the codebase (grepped) -- nothing populates them, ever, regardless of bug-1735's fix.",
"file": "src/worker/src/xcecd_cgroups.c (collect_job_rusages -- already sends memory_swap/tasks_current, no controller-side field to receive them), src/include/xce/types.h (xce_host_runusage_t -- would need new fields for swap/task-count; xce_job_runusage_t -- the peak/efficiency fields with no producer), src/controller/misc.c (update_host_runusage -- would need new parse branches), src/controller/job.c (update_job_rusages -- same open FIXME as bug-1735, this is the other half of what it would need to cover)",
"root_cause": "See bug-1735's root_cause for the full original investigation (resname-mismatch mechanism, environment-limitation note re: this session's sandbox having no real cgroup-backed worker to live-verify against) -- this entry covers only the subset of that finding split out as lower-priority. Unlike bug-1735's memory/cpu_time (which have existing-but-mismatched fields), memory_swap/tasks_current have NO receiving field in xce_host_runusage_t at all -- the worker's measurement is a complete dead end on the controller side, not a naming mismatch. The peak/efficiency fields (xce_job_runusage_t's own top-level fields) are simply never computed by anything, anywhere -- confirmed via grep, no partial implementation exists to build on.",
"fix": "NOT FIXED -- low priority, no scheduling impact identified, logged for whenever operator-facing job-accounting/reporting detail becomes a priority. RECOMMENDED SCOPE if picked up: (1) extend xce_host_runusage_t with swap/task-count fields and wire update_host_runusage() to parse 'memory_swap'/'tasks_current' alongside bug-1735's mem/cputime fix; (2) design and implement the peak/efficiency computations (peak_cpu_time/peak_cpu_duration would need tracking the running max across reports, not just the latest value; mem_efficiency/avg_cpu_efficiency/peak_cpu_efficiency need a defined formula against requested resources that doesn't exist yet -- this is closer to a small design task than a bug fix, unlike bug-1735's two clean, well-scoped corrections).",
"fix": "PARTIALLY FIXED (2026-08-30). Of the two gaps this entry covers:\n\n(1) memory_swap/tasks_current -- FIXED. Added mem_swap (double)/tasks_current (int) fields to xce_host_runusage_t (types.h), matching capnp fields (memSwap @3/tasksCurrent @4) appended to the HostRunusage schema (controller.capnp) for WAL field-completeness, parsing in update_host_runusage() (misc.c) for the worker's 'memory_swap'/'tasks_current' resnames, and per-host copy in merge_job_runusage()'s (job.c) existing-host branch (the new fields would otherwise have been silently dropped on WAL replay/catchup for a host already seen).\n\n(2) peak_cpu_time -- FIXED. aggregate_job_runusage() (misc.c) now tracks it as the running MAX of the per-call cpu_time sum across every report a job has ever received (not just the latest), guarding against a later report reducing it (e.g. an out-of-order merge/replay).\n\nSTILL NOT FIXED, DELIBERATELY (documented scope decision, not an oversight -- see aggregate_job_runusage()'s own doc comment in misc.c): peak_cpu_duration and the three efficiency fields (mem_efficiency/avg_cpu_efficiency/peak_cpu_efficiency). These need a 'used vs. requested' ratio against a job's resource request (a resreq expression tree, not a plain core/slot count) and/or an unspecified duration semantic -- genuine product/design decisions, not a formula that can be safely guessed. Left at their existing zero value rather than populated with an invented number that could mislead an operator.\n\nVerified: full `meson test --suite controller` clean, Ok:6 Fail:0, 1220/1220 individual controller_unit_test cases pass (zero regression from touching the shared xce_host_runusage_t struct + its capnp schema), plus 2 new regression tests in test_host_runusage.c (7/7 cases pass).",
"tags": [
"worker",
"controller",
@ -20067,17 +20069,19 @@
"priority-low",
"split-2026-08-30",
"no-scheduling-impact",
"unfixed",
"static-analysis-only",
"unreproduced-in-sandbox",
"needs-owner",
"needs-design-not-just-fix"
"needs-design-not-just-fix",
"partially-fixed",
"peak-cpu-time-fixed",
"swap-taskcount-fixed",
"efficiency-fields-remain-scope-decision"
],
"related_bugs": [
"bug-1735"
],
"occurrences": 1,
"last_seen": "2026-08-30T10:45:00Z"
"last_seen": "2026-08-30T08:35:00"
}
]
}
}