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

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

Browse source
This commit is contained in:
Rongsong Shen 2026-08-23 02:56:14 +00:00
parent ca01509f1b
commit 45acce4184
No known key found for this signature in database
GPG key ID: 5BCDAAE0123E9FE2
1 changed files with 25 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

25
.wolf/buglog.json
View file

@ -18231,6 +18231,31 @@
],
"occurrences": 1,
"last_seen": "2026-08-22T12:40:00Z"
},
{
"id": "bug-1624",
"timestamp": "2026-08-22T19:53:00Z",
"error_message": "None yet observed at runtime -- found via code trace while answering an architectural question about job RUN-state boundaries and over/under-commit safety.",
"file": "src/scheduler/src/scheduler.c, src/scheduler/src/core_session.c, src/scheduler/src/resource.c",
"root_cause": "sched_account_jobs() (scheduler.c:1258-1292) re-derives core->sharedInUse/worker->resInUse every round from scratch, but gates on JOB_IS_RUN(job->state) before checking job->accounts. A job that has been DISPATCHED (job->accounts set synchronously at commit-decision time via sched_commit_job_alloc(), scheduler.c:1446) but not yet confirmed RUN by the worker is still job->state==PEND, so it is skipped by this resum. Since xce_core_begin_session() (core_session.c:66-108) unconditionally zeroes sharedInUse/resInUse every round (normal-mode cadence: 1s, main.c:453-460), that job's charge -- correct within the round it was dispatched -- is wiped at the very next round and not restored until the RUN confirmation is processed. The admission check other jobs go through (sched_check_host_satisfy_/sched_check_shared_satisfy_, resource.c:252-370, called from seqjob_allocator.c:130) reads exactly this same resInUse/sharedInUse, with no separate reserved/committed pool (xce_sched_job_t has only state/allocs/accounts, sched/types.h:96-116) -- so once wiped, the resource looks free again and can be granted to a second job, a genuine over-commit/double-booking risk under any dispatch-to-worker-confirmation latency exceeding ~1 round (ordinary for real worker RPC + fork/exec).",
"fix": "NOT YET FIXED -- found during investigation, not yet remediated. Candidate direction: sched_account_jobs() (or an equivalent pass) needs to also re-sum jobs with accounts != NULL regardless of RUN state (mirroring the same decouple-from-state-gate pattern already being applied to simulation-mode capture in the scheduler-sim-eager-reconciliation spec), OR resInUse/sharedInUse charges need to survive the per-round reset for dispatched-but-unconfirmed jobs some other way. Needs its own spec -- this is normal-mode live-accounting correctness, explicitly out of scope for scheduler-sim-eager-reconciliation (which only touches simulation-mode capture/observability).",
"tags": [
"scheduler",
"resource-accounting",
"over-commit",
"double-booking",
"normal-mode",
"sched_account_jobs",
"JOB_IS_RUN",
"race-condition",
"unfixed"
],
"related_bugs": [
"bug-1611",
"bug-1613"
],
"occurrences": 1,
"last_seen": "2026-08-22T19:53:00Z"
}
]
}