Rongsong Shen
590860f73d
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>
59 lines
3.1 KiB
Markdown
59 lines
3.1 KiB
Markdown
---
|
|
id: "bug-1899"
|
|
status: "open"
|
|
status_updated: "2026-10-01"
|
|
status_note: "newly logged"
|
|
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"]
|
|
---
|
|
|
|
# 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
|
|
TODO: required for fixed/partial
|
|
|
|
## Fix
|
|
TODO: required for fixed/partial
|
|
|
|
## Verification
|
|
- Test: TODO: name + file; RED before the fix, GREEN after
|
|
- Suites: TODO: suite results and build profile
|
|
- Live: TODO: soak/deploy run, or n/a and why
|
|
|
|
## References
|
|
- Related: bug-1898 (same review), bug-1896 (spec job-array-one-based-index restructures this handler)
|