From 77b5102b3eec1bbfa8a520684ed4be34a5c6ddfc Mon Sep 17 00:00:00 2001 From: Rongsong Shen Date: Fri, 2 Oct 2026 03:45:06 +0000 Subject: [PATCH] docs(buglog): bug-1898 fixed (restart path in c73708b8) Co-Authored-By: Claude Opus 5.5 (1M context) --- .wolf/buglog.json | 14 +++++++++----- .wolf/bugs/bug-1898.md | 13 +++++++------ 2 files changed, 16 insertions(+), 11 deletions(-) diff --git a/.wolf/buglog.json b/.wolf/buglog.json index 7bc9b5c8..28be3793 100644 --- a/.wolf/buglog.json +++ b/.wolf/buglog.json @@ -16701,9 +16701,9 @@ }, { "id": "bug-1898", - "status": "partial", - "status_updated": "2026-10-01", - "status_note": "query + filter-control paths fixed (3457d892, 40917a01); RestartJobByID still builds unevaluated CompFilterConditions (restart out of scope)", + "status": "fixed", + "status_updated": "2026-10-02", + "status_note": "", "component": "apiserver", "severity": "wrong-result", "timestamp": "2026-10-01T04:26:54Z", @@ -16712,7 +16712,7 @@ "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)\n\nUPDATE (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.", "file": "src/frontend/apiserver/store/query.go, src/frontend/apiserver/utils/types.go, src/frontend/apiserver/controllers/jobs.go", "root_cause": "Bracketed `job_id`/`job_name` filter values were turned into `CompFilterCondition`s 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). Remaining: `RestartJobByID` (`controllers/jobs.go` ~:863) still builds unevaluated `CompFilterCondition`s; restart by identity is out of scope of that spec.\n\nVerification:\n- 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\n- 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\n- Live: pending (spec task 10.2 exercises the REST query and control flow)", + "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 `[k]` is restarted, an unknown job or element is not found, a bare array identity (several elements) is refused with 400. No handler builds `CompFilterCondition`s any more.\n\nVerification:\n- 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, `[2]`, unknown ID, missing element, bare array -- copied the first stored decoy job), GREEN after\n- 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\n- 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)", "tags": [ "apiserver", "job-array", @@ -16723,7 +16723,11 @@ "related_bugs": [ "bug-1896" ], - "fix_commits": [], + "fix_commits": [ + "3457d892", + "40917a01", + "c73708b8" + ], "record": ".wolf/bugs/bug-1898.md" }, { diff --git a/.wolf/bugs/bug-1898.md b/.wolf/bugs/bug-1898.md index b4ff70eb..a8b38508 100644 --- a/.wolf/bugs/bug-1898.md +++ b/.wolf/bugs/bug-1898.md @@ -1,8 +1,8 @@ --- id: "bug-1898" -status: "partial" -status_updated: "2026-10-01" -status_note: "query + filter-control paths fixed (3457d892, 40917a01); RestartJobByID still builds unevaluated CompFilterConditions (restart out of scope)" +status: "fixed" +status_updated: "2026-10-02" +status_note: "" component: "apiserver" severity: "wrong-result" timestamp: "2026-10-01T04:26:54Z" @@ -11,6 +11,7 @@ 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"] +fix_commits: ["3457d892", "40917a01", "c73708b8"] --- # bug-1898: apiserver ignores [..] job_id/job_name filters: CompConditions never evaluated @@ -51,12 +52,12 @@ UPDATE (2026-10-01): Task 7.3 (3457d892) fixes the query paths (GetJobsInfo, Get Bracketed `job_id`/`job_name` filter values were turned into `CompFilterCondition`s 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). Remaining: `RestartJobByID` (`controllers/jobs.go` ~:863) still builds unevaluated `CompFilterCondition`s; restart by identity is out of scope of that spec. +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 `[k]` is restarted, an unknown job or element is not found, a bare array identity (several elements) is refused with 400. No handler builds `CompFilterCondition`s 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 +- 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, `[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: pending (spec task 10.2 exercises the REST query and control flow) +- 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)