docs(job-array-one-based-index): feature validation round 1 follow-ups

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>

2026-10-01 15:50:10 +00:00

3.6 KiB

Raw Blame History

id status status_updated status_note component severity timestamp last_seen occurrences files tags related

bug-1903

partial

2026-10-01

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

apiserver

wrong-result

2026-10-01T12:21:25Z

src/frontend/apiserver/controllers/jobs.go

src/frontend/apiserver/store/query.go

apiserver

query

pagination

code-review

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

In a controllers handler test (non-cgo, jobs_handler_test.go fixture), seed more jobs than the page limit.
GET /xce/v1/jobs?filter={submit_user:eq:all}&limit=2; read page_token from the response.
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:

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

3.6 KiB Raw Blame History