docs(job-array-one-based-index): requirements, design and tasks; log bug-1898, bug-1899

Spec for numbering job-array elements from 1 (bug-1896): approved
requirements, a design reviewed over 20 rounds until clean (log in
research.md), and a 30-task plan. The design review found two live
apiserver defects, logged here: bracketed job_id/job_name filters are
never evaluated (bug-1898) and ControlJobByID re-dispatches earlier
selections (bug-1899).

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

2026-10-01 08:54:06 +00:00

3.1 KiB

Raw Blame History

status

status_updated

status_note

component

severity

timestamp

last_seen

occurrences

files

bug-1899: ControlJobByID re-dispatches earlier selections on every later selection of one request

Description

Observed: found by code review, no failing run captured yet. In ControlJobByID the slice successJobs is declared once before the loop over the request's selections (src/frontend/apiserver/controllers/jobs.go:2464), is appended to inside that loop (:2575-2583), and the dispatch loop over the whole accumulated slice also sits inside it (:2594-2617):

successJobs := []map[string]interface{}{}            // :2464, outside
for _, ujobFilterCdArray := range allFiltCdArrays {   // one per selection
    ...
    successJobs = append(successJobs, ...)           // :2575
    if len(successJobs) > 0 {
        for _, successJob := range successJobs {      // re-sends all earlier ones
            err = backend.ControlJob(...)              // :2611

Expected: each selected job receives the control action once per request; the response lists it once. Impact: wrong result: xcecli jobs kill X[1],Y[2] (or kill A,B) signals the first selection's jobs once per later selection (N selections -> the first job is sent N times); a repeated kill of an already-killed job can make the backend call fail and the request report an error; BuildBatchOperationResponse receives the accumulated slice, so the response lists earlier jobs repeatedly. Distinct from the out-of-scope duplicate-signal case of one element selected twice (job-array-one-based-index requirements). Found by: review (design review round 11 of spec job-array-one-based-index, 2026-10-01)

Environment

OS: no /etc/os-release; Docker container; NixOS kernel; kernel Linux 6.18.33 x86_64
libc: n/a (pure-Go control handler); host glibc 2.40
Toolchain: gcc (GCC) 15.2.0, meson 1.9.1
Build: asan (xce.build); defect is in pure Go, independent of profile
Code: scheduler-framework @ 8f5ba635-dirty
Deployment: any (single-node or HA) with at least two controllable jobs

Reproduction

Read src/frontend/apiserver/controllers/jobs.go:2464-2620 (ControlJobByID): the backend.ControlJob loop over successJobs is inside the per-selection loop.
Live: submit two sleep 300 jobs A and B; xcecli jobs stop A,B; the controller log shows the stop for A twice.

Frequency: deterministic (by code reading; not yet run)
Evidence: not kept (code reading only)

Root cause

TODO: required for fixed/partial

Fix