chore(buglog): log bug-1903 (GetJobsInfo pagination); note bug-1898 progress
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
This commit is contained in:
parent
3457d892b6
commit
c3962e8f61
GPG key ID:
80533536B0EB651C
3 changed files with 78 additions and 1 deletions
|
|
@ -16704,7 +16704,7 @@
|
|||
"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)",
|
||||
"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": "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",
|
||||
|
|
@ -16829,6 +16829,30 @@
|
|||
"fix_commits": [],
|
||||
"record": ".wolf/bugs/bug-1902.md",
|
||||
"repro_attempts": "0/5 reruns, 2026-10-01 (4 targeted meson reruns + reviewer full run)"
|
||||
},
|
||||
{
|
||||
"id": "bug-1903",
|
||||
"status": "open",
|
||||
"status_updated": "2026-10-01",
|
||||
"status_note": "newly logged",
|
||||
"component": "apiserver",
|
||||
"severity": "wrong-result",
|
||||
"timestamp": "2026-10-01T12:21:25Z",
|
||||
"last_seen": "2026-10-01T12:21:25Z",
|
||||
"occurrences": 1,
|
||||
"error_message": "apiserver GetJobsInfo page_token does not advance: the next page repeats the first\n\n**Observed:** found by the reviewer of task 7.3 (spec job-array-one-based-index) while comparing handler behaviour with HEAD in a unit-test harness: following the `page_token` returned by `GET /xce/v1/jobs` (`GetJobsInfo`) returns the same page again instead of the next one. Reproduced at HEAD (before task 7.3) with a plain filter `{submit_user:eq:all}` and a small `limit`, so it is not caused by the element-selection work.\n**Expected:** passing the returned `page_token` yields the next page of rows, and the last page returns no token.\n**Impact:** wrong result: clients that page through job listings (`xcecli jobs list` with paging, REST callers) see the first page repeatedly and never reach later jobs.\n**Found by:** review (task 7.3 of spec job-array-one-based-index, 2026-10-01)",
|
||||
"file": "src/frontend/apiserver/controllers/jobs.go, src/frontend/apiserver/store/query.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",
|
||||
"query",
|
||||
"pagination",
|
||||
"code-review"
|
||||
],
|
||||
"related_bugs": [],
|
||||
"fix_commits": [],
|
||||
"record": ".wolf/bugs/bug-1903.md"
|
||||
}
|
||||
]
|
||||
}
|
||||
|
|
|
|||
|
|
@ -30,6 +30,8 @@ So the bracketed selection is silently dropped: `GetJobsInfo` (`job_id`/`job_nam
|
|||
**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
|
||||
|
|
|
|||
51
.wolf/bugs/bug-1903.md
Normal file
51
.wolf/bugs/bug-1903.md
Normal file
|
|
@ -0,0 +1,51 @@
|
|||
---
|
||||
id: "bug-1903"
|
||||
status: "open"
|
||||
status_updated: "2026-10-01"
|
||||
status_note: "newly logged"
|
||||
component: "apiserver"
|
||||
severity: "wrong-result"
|
||||
timestamp: "2026-10-01T12:21:25Z"
|
||||
last_seen: "2026-10-01T12:21:25Z"
|
||||
occurrences: 1
|
||||
files: ["src/frontend/apiserver/controllers/jobs.go", "src/frontend/apiserver/store/query.go"]
|
||||
tags: ["apiserver", "query", "pagination", "code-review"]
|
||||
related: []
|
||||
---
|
||||
|
||||
# bug-1903: apiserver GetJobsInfo page_token does not advance: the next page repeats the first
|
||||
|
||||
## Description
|
||||
**Observed:** found by the reviewer of task 7.3 (spec job-array-one-based-index) while comparing handler behaviour with HEAD in a unit-test harness: following the `page_token` returned by `GET /xce/v1/jobs` (`GetJobsInfo`) returns the same page again instead of the next one. Reproduced at HEAD (before task 7.3) with a plain filter `{submit_user:eq:all}` and a small `limit`, so it is not caused by the element-selection work.
|
||||
**Expected:** passing the returned `page_token` yields the next page of rows, and the last page returns no token.
|
||||
**Impact:** wrong result: clients that page through job listings (`xcecli jobs list` with paging, REST callers) see the first page repeatedly and never reach later jobs.
|
||||
**Found by:** review (task 7.3 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 handler path); host glibc 2.40
|
||||
- Toolchain: gcc (GCC) 15.2.0, meson 1.9.1, Go from the nix dev shell
|
||||
- Build: asan (build.jai); exercised through the non-cgo Go unit-test build of src/frontend/apiserver (the defect is in pure Go)
|
||||
- Code: scheduler-framework @ c30e5f1d (HEAD before task 7.3) and 3457d892
|
||||
- Deployment: none (controllers handler test with an in-memory store); any apiserver with more jobs than the page limit
|
||||
|
||||
## Reproduction
|
||||
1. In a controllers handler test (non-cgo, `jobs_handler_test.go` fixture), seed more jobs than the page limit.
|
||||
2. `GET /xce/v1/jobs?filter={submit_user:eq:all}&limit=2`; read `page_token` from the response.
|
||||
3. Repeat the request adding `&page_token=<token>`: the rows are the same as the first page.
|
||||
- Frequency: deterministic (reviewer probe, 2026-10-01)
|
||||
- Evidence: not kept (reviewer's temporary probe test, deleted)
|
||||
|
||||
## 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 (found while fixing it)
|
||||
Loading…
Add table
Add a link
Reference in a new issue