myxce/.wolf/bugs/bug-1898.md

id	status	status_updated	status_note	component	severity	timestamp	last_seen	occurrences	files	tags	related	fix_commits
bug-1898	fixed	2026-10-02		apiserver	wrong-result	2026-10-01T04:26:54Z	2026-10-01T04:26:54Z	1	src/frontend/apiserver/store/query.go src/frontend/apiserver/utils/types.go src/frontend/apiserver/controllers/jobs.go	apiserver job-array query control code-review	bug-1896	3457d892 40917a01 c73708b8

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)

UPDATE (2026-10-01): Task 7.3 (3457d892) fixes the query paths (GetJobsInfo, GetJobByIDs); the filter-based control path follows in 7.5. RestartJobByID still builds unevaluated CompFilterConditions; restart by identity is out of scope of spec job-array-one-based-index.

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

Bracketed job_id/job_name filter values were turned into CompFilterConditions and removed from the plain filters, but store.ExecuteQuery only ever evaluated opts.Conditions; nothing read opts.CompConditions. The conditions were therefore silently dropped on every path that built them (GetJobsInfo, GetJobByIDs, FetchJobList used by filter-based ControlJob, and RestartJobByID). The ConditionArray shape also had no AND slot for an element-only term, so the compound conditions could not have expressed the selection even if evaluated.

Fix

Spec job-array-one-based-index replaces the compound conditions with evaluated row predicates on the owned paths: QueryOptions.Predicates evaluated by store.ExecuteQuery after the plain conditions and before sort/pagination (task 5.3, 46f57095); BuildSelectionPredicates honouring each operator (task 7.2, 675d7d7f); GetJobsInfo and GetJobByIDs (task 7.3, 3457d892); filter-based ControlJob / FetchJobList (task 7.5, 40917a01). c73708b8 fixes the last path, RestartJobByID: it restarted jqueryReply[0] of an unevaluated job_id CompCondition -- the first stored job, for any ID, unknown ones included. It now parses the ID with ParseIdentitySelection, fetches rows by key (queryControlRowsByJobID) and matches with foundJob, as ControlJobByID does: an ordinary job or <array-id>[k] is restarted, an unknown job or element is not found, a bare array identity (several elements) is refused with 400. No handler builds CompFilterConditions any more.

Verification

• Test: TestJobHandler_QuerySelections / TestJobHandler_GetJobByIDsSelections (task 7.3) and TestJobHandler_ControlFilterElementSelection* (task 7.5) in src/frontend/apiserver/controllers/jobs_handler_test.go: RED before (job_id:eq:X[2] returned all 10 seeded rows; -J 'foo[1]' acted on 6 jobs incl. ordinary ones), GREEN after; TestJobHandler_RestartNamedJob (same file): RED before c73708b8 (every restart -- ordinary, <array-id>[2], unknown ID, missing element, bare array -- copied the first stored decoy job), GREEN after
• Suites: apiserver non-cgo unit tests (controllers, store, utils, backend) and the cgo build via xce-build.sh apiserver asan build.jai, passing, 2026-10-01
• Live: query and control verified live in spec task 10.2 (xce-deploy-ha + xcecli, 2026-10-01); restart verified at handler level only (the REST handler against the real store in the test fixture)

References

• Related: bug-1896 (found while designing its fix, spec job-array-one-based-index)