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>
60 lines
3.4 KiB
Markdown
60 lines
3.4 KiB
Markdown
---
|
|
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)
|