---
id: "bug-1899"
status: "fixed"
status_updated: "2026-10-01"
status_note: ""
component: "apiserver"
severity: "wrong-result"
timestamp: "2026-10-01T05:10:35Z"
last_seen: "2026-10-01T05:10:35Z"
occurrences: 1
files: ["src/frontend/apiserver/controllers/jobs.go"]
tags: ["apiserver", "control", "job-array", "code-review"]
related: ["bug-1898", "bug-1896"]
fix_commits: ["40207402"]
---

# 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`):
```go
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
1. Read `src/frontend/apiserver/controllers/jobs.go:2464-2620` (`ControlJobByID`): the `backend.ControlJob` loop over `successJobs` is inside the per-selection loop.
2. 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
In `ControlJobByID` (`src/frontend/apiserver/controllers/jobs.go`), `successJobs` was declared once outside the loop over the request's selections and appended to inside it, while the `backend.ControlJob` dispatch loop over the whole accumulated slice also sat inside the per-selection loop. Every later selection therefore re-dispatched all jobs collected for earlier selections, and the response was built from the accumulated slice.

## Fix
Task 7.4 of spec job-array-one-based-index restructures the handler: all selections are validated before any store access; the selection loop only collects the jobs to act on (de-duplicated by `unique_job_id`) and the per-number not-found results; after the loop each job is validated once with `validateJobControl` and each accepted job is dispatched exactly once through `controlJob`.

## Verification
- Test: `TestJobHandler_ControlTwoSelectionsDispatchOnce` in `src/frontend/apiserver/controllers/jobs_handler_test.go`: RED before (X[1],Y[2] dispatched [x1 x1 x1 x1 y2 y2]; A,B dispatched [A A A A B B]), GREEN after ([x1 y2], [A B])
- Suites: apiserver non-cgo unit tests (controllers, store, utils, backend) and the cgo build via `xce-build.sh apiserver asan build.jai`, all passing, 2026-10-01
- Live: n/a here; the live REST control flow is exercised in task 10.2 of the spec

## References
- Related: bug-1898 (same review), bug-1896 (spec job-array-one-based-index restructures this handler)