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>
This commit is contained in:
parent
8f5ba635c5
commit
590860f73d
GPG key ID:
80533536B0EB651C
8 changed files with 1725 additions and 0 deletions
|
|
@ -16693,6 +16693,60 @@
|
|||
"0fe27d4b"
|
||||
],
|
||||
"record": ".wolf/bugs/bug-1897.md"
|
||||
},
|
||||
{
|
||||
"id": "bug-1898",
|
||||
"status": "open",
|
||||
"status_updated": "2026-10-01",
|
||||
"status_note": "newly logged",
|
||||
"component": "apiserver",
|
||||
"severity": "wrong-result",
|
||||
"timestamp": "2026-10-01T04:26:54Z",
|
||||
"last_seen": "2026-10-01T04:26:54Z",
|
||||
"occurrences": 1,
|
||||
"error_message": "apiserver ignores [..] job_id/job_name filters: CompConditions never evaluated\n\n**Observed:** found by code review, no failing run captured yet. Every REST selection value containing `[` and `]` is turned into a `CompFilterCondition`, removed from the plain filters and passed to `utils.BuildQueryOptions` as `CompConditions`, but `store.ExecuteQuery` evaluates only `opts.Conditions`:\n```go\n// src/frontend/apiserver/store/query.go:19-22\nif len(opts.Conditions) > 0 {\n rows = FilterRows(rows, opts.Conditions)\n}\n// opts.CompConditions (utils/types.go:96, set at :454) is never read anywhere\n```\nSo the bracketed selection is silently dropped: `GetJobsInfo` (`job_id`/`job_name` with `[...]`, `controllers/jobs.go:186,494-510`), `GetJobByIDs` (`:780,961`) and `FetchJobList` (`:3311,3420-3436,3463`, used by filter-based `ControlJob`) return every row that matches the remaining filters.\n\n**Expected:** a selection such as `job_id:eq:X[2]` or `job_name:eq:foo[1-3]` returns only the matching array elements; a control command `xcecli jobs kill -J 'foo[1]'` acts only on element 1 of arrays named `foo`.\n**Impact:** wrong result, and for control a wrong target: `xcecli jobs list X[2]` lists unrelated jobs; filter-based control with `-J 'name[k]'` and no other filter matches all jobs, and its \"most recent job\" rule (`jobs.go:2752-2757`) then kills/stops/resumes the newest job in the cluster instead of the named element. `ControlJobByID` is not affected (it post-filters with `foundJob`).\n**Found by:** review (design review of spec `job-array-one-based-index`, 2026-10-01)",
|
||||
"file": "src/frontend/apiserver/store/query.go, src/frontend/apiserver/utils/types.go, 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",
|
||||
"tags": [
|
||||
"apiserver",
|
||||
"job-array",
|
||||
"query",
|
||||
"control",
|
||||
"code-review"
|
||||
],
|
||||
"related_bugs": [
|
||||
"bug-1896"
|
||||
],
|
||||
"fix_commits": [],
|
||||
"record": ".wolf/bugs/bug-1898.md"
|
||||
},
|
||||
{
|
||||
"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,
|
||||
"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",
|
||||
"tags": [
|
||||
"apiserver",
|
||||
"control",
|
||||
"job-array",
|
||||
"code-review"
|
||||
],
|
||||
"related_bugs": [
|
||||
"bug-1898",
|
||||
"bug-1896"
|
||||
],
|
||||
"fix_commits": [],
|
||||
"record": ".wolf/bugs/bug-1899.md"
|
||||
}
|
||||
]
|
||||
}
|
||||
|
|
|
|||
60
.wolf/bugs/bug-1898.md
Normal file
60
.wolf/bugs/bug-1898.md
Normal file
|
|
@ -0,0 +1,60 @@
|
|||
---
|
||||
id: "bug-1898"
|
||||
status: "open"
|
||||
status_updated: "2026-10-01"
|
||||
status_note: "newly logged"
|
||||
component: "apiserver"
|
||||
severity: "wrong-result"
|
||||
timestamp: "2026-10-01T04:26:54Z"
|
||||
last_seen: "2026-10-01T04:26:54Z"
|
||||
occurrences: 1
|
||||
files: ["src/frontend/apiserver/store/query.go", "src/frontend/apiserver/utils/types.go", "src/frontend/apiserver/controllers/jobs.go"]
|
||||
tags: ["apiserver", "job-array", "query", "control", "code-review"]
|
||||
related: ["bug-1896"]
|
||||
---
|
||||
|
||||
# bug-1898: apiserver ignores [..] job_id/job_name filters: CompConditions never evaluated
|
||||
|
||||
## Description
|
||||
**Observed:** found by code review, no failing run captured yet. Every REST selection value containing `[` and `]` is turned into a `CompFilterCondition`, removed from the plain filters and passed to `utils.BuildQueryOptions` as `CompConditions`, but `store.ExecuteQuery` evaluates only `opts.Conditions`:
|
||||
```go
|
||||
// src/frontend/apiserver/store/query.go:19-22
|
||||
if len(opts.Conditions) > 0 {
|
||||
rows = FilterRows(rows, opts.Conditions)
|
||||
}
|
||||
// opts.CompConditions (utils/types.go:96, set at :454) is never read anywhere
|
||||
```
|
||||
So the bracketed selection is silently dropped: `GetJobsInfo` (`job_id`/`job_name` with `[...]`, `controllers/jobs.go:186,494-510`), `GetJobByIDs` (`:780,961`) and `FetchJobList` (`:3311,3420-3436,3463`, used by filter-based `ControlJob`) return every row that matches the remaining filters.
|
||||
|
||||
**Expected:** a selection such as `job_id:eq:X[2]` or `job_name:eq:foo[1-3]` returns only the matching array elements; a control command `xcecli jobs kill -J 'foo[1]'` acts only on element 1 of arrays named `foo`.
|
||||
**Impact:** wrong result, and for control a wrong target: `xcecli jobs list X[2]` lists unrelated jobs; filter-based control with `-J 'name[k]'` and no other filter matches all jobs, and its "most recent job" rule (`jobs.go:2752-2757`) then kills/stops/resumes the newest job in the cluster instead of the named element. `ControlJobByID` is not affected (it post-filters with `foundJob`).
|
||||
**Found by:** review (design review 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 (Go apiserver, pure-Go query path); host glibc 2.40
|
||||
- Toolchain: gcc (GCC) 15.2.0, meson 1.9.1
|
||||
- Build: asan (xce.build); the defect is in pure Go and independent of the profile
|
||||
- Code: scheduler-framework @ 8f5ba635-dirty
|
||||
- Deployment: any (single-node or HA) with at least one job array and one other job
|
||||
|
||||
## Reproduction
|
||||
1. Read `src/frontend/apiserver/store/query.go:15-42` (`ExecuteQuery`) and `grep -rn CompConditions src/frontend/apiserver --include=*.go` (only `utils/types.go:96,454` -- never read).
|
||||
2. Unit-test sketch: put an array element `X[1]`, `X[2]` and an ordinary job `Y` into `store.Jobs`; call `GetJobsInfo` with `filter=job_id:eq:<X>[2]`; expected only `X[2]`, today all three rows.
|
||||
3. Live: submit `xcecli jobs submit -J 'foo[1-2]' sleep 300` and an ordinary `sleep 300`; run `xcecli jobs kill -J 'foo[1]'` -- the newest job is signalled, not `foo[1]`.
|
||||
- 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-1896 (found while designing its fix, spec job-array-one-based-index)
|
||||
59
.wolf/bugs/bug-1899.md
Normal file
59
.wolf/bugs/bug-1899.md
Normal file
|
|
@ -0,0 +1,59 @@
|
|||
---
|
||||
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)
|
||||
Loading…
Add table
Add a link
Reference in a new issue