Rongsong Shen
0f4effe7df
bug-1903 partial (page-token precision fixed in efff6b65), bug-1907
logged (harness setpend/jobrun cannot report not-found), stale
parse_jobid regex comment in repl.c updated.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
53 lines
3.6 KiB
Markdown
53 lines
3.6 KiB
Markdown
---
|
|
id: "bug-1903"
|
|
status: "partial"
|
|
status_updated: "2026-10-01"
|
|
status_note: "page-token float64 precision loss for array element IDs fixed in efff6b65; the original GetJobsInfo repeat-first-page symptom with plain jobs is still unexplained"
|
|
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
|
|
Two separate parts:
|
|
1. (found 2026-10-01, fixed) `store/query.go` `findPageTokenIndex` decoded the token with `json.Unmarshal` into `interface{}`, so `unique_job_id` became a float64. Array element IDs set bit 62, where float64 spacing is 1024, so the token no longer named the page's last row: paging skipped rows (N >= 1024) or found no match and restarted at row 0 (1001 <= N <= 1023). `queryControlRowsByJobID`, `FetchJobList` and `GetJobByIDs` page until the token is empty, so the restart case loops forever.
|
|
2. (open) The originally observed repeat-the-first-page with plain jobs and a small `limit` in `GetJobsInfo` is not explained by part 1 for IDs below 2^53; cause not yet found.
|
|
|
|
## Fix
|
|
Part 1: efff6b65. `findPageTokenIndex` decodes with `json.Decoder.UseNumber()` and converts integers to int64 (floats stay float64). Part 2: not yet fixed.
|
|
|
|
## Verification
|
|
- Test: (part 1) `TestPaginateRowsArrayElementIDsRoundTripPageToken` in `src/frontend/apiserver/store/query_test.go`; RED before the fix (2452 of 2500 rows), GREEN after
|
|
- Suites: apiserver store/utils/controllers go test ok (CGO_ENABLED=0)
|
|
- Live: n/a (unit-level; part 2 still needs a reproduction)
|
|
|
|
## References
|
|
- Related: bug-1898 (found while fixing it)
|