chore(buglog): bug-1899 fixed (40207402)

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

.wolf/buglog.json

@@ -16723,9 +16723,9 @@
     },
     {
       "id": "bug-1899",
-      "status": "open",
+      "status": "fixed",
       "status_updated": "2026-10-01",
-      "status_note": "newly logged",
+      "status_note": "",
       "component": "apiserver",
       "severity": "wrong-result",
       "timestamp": "2026-10-01T05:10:35Z",
@@ -16733,8 +16733,8 @@
       "occurrences": 1,
       "error_message": "ControlJobByID re-dispatches earlier selections on every later selection of one request\n\n**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`):\n```go\nsuccessJobs := []map[string]interface{}{}            // :2464, outside\nfor _, ujobFilterCdArray := range allFiltCdArrays {   // one per selection\n    ...\n    successJobs = append(successJobs, ...)           // :2575\n    if len(successJobs) > 0 {\n        for _, successJob := range successJobs {      // re-sends all earlier ones\n            err = backend.ControlJob(...)              // :2611\n```\n**Expected:** each selected job receives the control action once per request; the response lists it once.\n**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).\n**Found by:** review (design review round 11 of spec `job-array-one-based-index`, 2026-10-01)",
       "file": "src/frontend/apiserver/controllers/jobs.go",
-      "root_cause": "TODO: required for fixed/partial",
-      "fix": "TODO: required for fixed/partial\n\nVerification:\n- Test: TODO: name + file; RED before the fix, GREEN after\n- Suites: TODO: suite results and build profile\n- Live: TODO: soak/deploy run, or n/a and why",
+      "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`.\n\nVerification:\n- 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])\n- 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\n- Live: n/a here; the live REST control flow is exercised in task 10.2 of the spec",
       "tags": [
         "apiserver",
         "control",
@@ -16745,7 +16745,9 @@
         "bug-1898",
         "bug-1896"
       ],
-      "fix_commits": [],
+      "fix_commits": [
+        "40207402"
+      ],
       "record": ".wolf/bugs/bug-1899.md"
     },
     {

.wolf/bugs/bug-1899.md

@@ -1,8 +1,8 @@
 ---
 id: "bug-1899"
-status: "open"
+status: "fixed"
 status_updated: "2026-10-01"
-status_note: "newly logged"
+status_note: ""
 component: "apiserver"
 severity: "wrong-result"
 timestamp: "2026-10-01T05:10:35Z"
@@ -11,6 +11,7 @@ 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
@@ -45,15 +46,15 @@ for _, ujobFilterCdArray := range allFiltCdArrays {   // one per selection
 - Evidence: not kept (code reading only)
 
 ## Root cause
-TODO: required for fixed/partial
+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
-TODO: required for fixed/partial
+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: 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
+- 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)