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>

2026-10-01 08:54:06 +00:00

3.4 KiB

Raw Blame History

status

status_updated

status_note

component

severity

timestamp

last_seen

occurrences

files

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:

// 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

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).
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.
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