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

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

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

44
.wolf/buglog.json
View file

@ -18256,6 +18256,50 @@
],
"occurrences": 1,
"last_seen": "2026-08-22T19:53:00Z"
},
{
"id": "bug-1625",
"timestamp": "2026-08-23T05:20:00Z",
"error_message": "None yet observed at runtime -- found via code trace while designing scheduler-dispatch-commit. Referenced throughout that spec's requirements.md/research.md/design.md by this id; being logged now after noticing it was never actually appended to buglog.json.",
"file": "src/scheduler/src/handler.c",
"root_cause": "The controller already reports dispatch-RPC failure back to the scheduler via NotifyData_data_jobDispatchFail (notify_dispatch(), src/controller/job.c:1108-1125), but sched_handle_notify()'s switch (handler.c:499-544) has no case for it -- it falls to default: rc = -EINVAL. A dispatch failure is therefore silently dropped by the scheduler: job->accounts/job->allocs (set synchronously at dispatch-decision-commit time by sched_commit_decision()) are never released, leaving stale committed-resource bookkeeping behind indefinitely.",
"fix": "NOT YET FIXED -- scoped as Requirement 3 of the scheduler-dispatch-commit spec (.kiro/specs/scheduler-dispatch-commit/, design-generated as of 2026-08-23). Design: add case NotifyData_data_jobDispatchFail to sched_handle_notify(), applying JOB_STAT_PEND via the existing XCE_SCHED_OP_JSTATE_CHANGE enqueue path (same shape as adjacent schedExitJob/schedFailJob cases) -- the existing core_events.c free-on-non-RUN logic then releases job->accounts/job->allocs with no new cleanup code needed.",
"tags": [
"scheduler",
"controller",
"dispatch-failure",
"notify",
"unhandled-event",
"resource-leak",
"unfixed"
],
"related_bugs": [
"bug-1624"
],
"occurrences": 1,
"last_seen": "2026-08-23T05:20:00Z"
},
{
"id": "bug-1626",
"timestamp": "2026-08-23T05:20:00Z",
"error_message": "None yet observed at runtime -- found via code trace during /kiro-validate-design review of scheduler-dispatch-commit.",
"file": "src/controller/job.c",
"root_cause": "apply_job_fail_transition() (job.c:1804-1836) is explicitly documented as safe to call only \"as long as the caller already holds job under RTTI_LOCK_WRITE\" (a genuine rwlock, my_rwlock_wlock(), confirmed via src/lib/jobj.c:708-725's job_lock()). Its existing caller mark_job_fail() (job.c:1844) is itself called from job_ctrl() (job.c:965) at line 1083 -- but job_ctrl()'s only lock on the job object across its entire body (traced lines 965-1090) is lock(j, RTTI_LOCK_READ) at line 999, released via unlock(j) at line 1016, well before the mark_job_fail() call at line 1083. No RTTI_LOCK_WRITE is ever taken in this path. Separately, dispatch_a_job_() (job.c:831-963) mutates j->job.allocs under only RTTI_LOCK_READ on the containing maps (c->jobmgr, c->workermgr) and RTTI_LOCK_READ on the worker w -- never RTTI_LOCK_WRITE on the job j itself. RTTI_LOCK_READ is a genuine reader lock (my_rwlock_rlock()) that does not exclude concurrent readers from each independently mutating the same object, so if two threads process job-mutating requests for the same job concurrently, this is a real data race, not just an inaccurate comment. Contrast: many OTHER call sites in the same file (e.g. job.c:768, 1687, 1795, 2058, 2089, 2127, 2169, 2206, 2293, 2340, 2416) DO correctly take RTTI_LOCK_WRITE before mutating job state, confirming RTTI_LOCK_WRITE is this codebase's established, intentional convention for job-state mutation -- the job_ctrl()/mark_job_fail() and dispatch_a_job_() call sites appear to be inconsistent outliers, not a different intentional design.",
"fix": "NOT YET FIXED -- discovered as a pre-existing gap while validating scheduler-dispatch-commit's design (that spec plans to add new mutations, including a WAL-fact-durable one, to dispatch_a_job_(), and reuse mark_job_fail() for its terminal dispatch-failure path -- both inherit this open question). Needs its own investigation: either (a) confirm some other serialization guarantee (e.g. single-threaded-per-job request processing) makes RTTI_LOCK_READ sufficient in practice and the RTTI_LOCK_WRITE comments/convention are overcautious, or (b) these call sites are missing a genuine lock upgrade and should take RTTI_LOCK_WRITE like their sibling call sites do. Flagged back to scheduler-dispatch-commit's design review as Critical Issue 1 rather than fixed inline, since it is a pre-existing condition this feature would otherwise silently inherit/extend, not something this feature caused.",
"tags": [
"controller",
"concurrency",
"locking",
"rwlock",
"RTTI_LOCK_WRITE",
"job-state-mutation",
"race-condition",
"pre-existing",
"unfixed"
],
"related_bugs": [],
"occurrences": 1,
"last_seen": "2026-08-23T05:20:00Z"
}
]
}