forked from lei.chen/myxce
c90e63ec0f
Two stacked defects in the apiserver job-control link, both of which kept hold/release/cancel from ever reaching the controller: 1. controllers/jobs.go: validateJobControl and foundJob asserted jobinfo.Data["array_idx"].(int64), but StoreToOrderMaps produces array_idx as int (models.JobInfo.ArrayIdx is declared int) -> panic -> Gin Recovery -> HTTP 500 before backend.ControlJob ran. Add normalizeJobInt64 / jobArrayIdx helpers and use them in both functions (job_status already had this fix via normalizeJobStatus; array_idx was missed). 2. backend/clib.go: backend.ControlJob set xce_jobctrl_t.action to the models.JOB_* constant (JOB_STOP=1 / JOB_RESUME=2 / JOB_KILL=3 / JOB_CHKPNT=8), but that field is the capnp JobControl union discriminant (JobControl_u_siginfo=0 / JobControl_u_ckptoption=1). The controller's job_ctrl() selected the wrong union branch (or none, since encode_JobControl drops the union pointer for non-0/1 discriminants) and rejected every control with -EINVAL. Add jobCtrlDiscriminant() and use it. Also: resolveExecUser was defined in the cgo-only convert.go but is exercised by a non-cgo test, so `make test` (CGO_ENABLED=0) failed to build the backend package. Move it to convert_pure.go so it compiles in both modes. Tests: 3 controller regression tests (validateJobControl allowed / not-allowed branches, foundJob array-child branch) + 1 backend jobCtrlDiscriminant test. make test fully green. Cluster E2E verified: hold -> PSUSP, release -> PEND, cancel -> EXIT on a PEND job, no 500, no -EINVAL, all daemons healthy. Co-Authored-By: Claude <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| superpowers/plans | ||
| Job-Finish-Robustness-设计文档.md | ||
| left_scheduler_work.md | ||
| Scheduler-Agent-设计文档.md | ||