diff --git a/.wolf/buglog.json b/.wolf/buglog.json index 9a7078d9..7bc9b5c8 100644 --- a/.wolf/buglog.json +++ b/.wolf/buglog.json @@ -16839,9 +16839,9 @@ }, { "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", + "status": "fixed", + "status_updated": "2026-10-02", + "status_note": "", "component": "apiserver", "severity": "wrong-result", "timestamp": "2026-10-01T12:21:25Z", @@ -16849,8 +16849,8 @@ "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": "Two separate parts:\n1. (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.\n2. (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.\n\nVerification:\n- Test: (part 1) `TestPaginateRowsArrayElementIDsRoundTripPageToken` in `src/frontend/apiserver/store/query_test.go`; RED before the fix (2452 of 2500 rows), GREEN after\n- Suites: apiserver store/utils/controllers go test ok (CGO_ENABLED=0)\n- Live: n/a (unit-level; part 2 still needs a reproduction)", + "root_cause": "`store/query.go` `findPageTokenIndex` decoded the token with `json.Unmarshal` into `interface{}`, so the token's `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: with no exact match `findPageTokenIndex` returned 0 and every page restarted at row 0 -- the reported repeat-the-first-page (the review fixture's rows are array elements); with a near match it skipped rows instead. `queryControlRowsByJobID`, `FetchJobList` and `GetJobByIDs` page until the token is empty, so the restart case also looped forever on arrays over 1000 elements.", + "fix": "efff6b65: `findPageTokenIndex` decodes with `json.Decoder.UseNumber()` and converts integers to int64 (floats stay float64), so 63-bit job IDs compare exactly. ffb3e098 adds the handler-level regression test.\n\nVerification:\n- Test: `TestJobHandler_QueryPagination` in `src/frontend/apiserver/controllers/jobs_handler_test.go` (GetJobsInfo, limit=3, follows `page_token`): RED with efff6b65's parent `store/query.go` (the same three rows returned on every page until the loop guard stopped it), GREEN after; `TestPaginateRowsArrayElementIDsRoundTripPageToken` in `store/query_test.go` (2500 array elements, limit 1000): RED before efff6b65 (2452 of 2500 rows), GREEN after\n- Suites: apiserver store/utils/controllers go test ok (CGO_ENABLED=0)\n- Live: n/a (unit/handler level: the REST handler runs against the real store in the fixture)", "tags": [ "apiserver", "query", @@ -16858,7 +16858,10 @@ "code-review" ], "related_bugs": [], - "fix_commits": [], + "fix_commits": [ + "efff6b65", + "ffb3e098" + ], "record": ".wolf/bugs/bug-1903.md" }, { diff --git a/.wolf/bugs/bug-1903.md b/.wolf/bugs/bug-1903.md index 019385a2..bfdc86d6 100644 --- a/.wolf/bugs/bug-1903.md +++ b/.wolf/bugs/bug-1903.md @@ -1,8 +1,8 @@ --- 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" +status: "fixed" +status_updated: "2026-10-02" +status_note: "" component: "apiserver" severity: "wrong-result" timestamp: "2026-10-01T12:21:25Z" @@ -11,6 +11,7 @@ occurrences: 1 files: ["src/frontend/apiserver/controllers/jobs.go", "src/frontend/apiserver/store/query.go"] tags: ["apiserver", "query", "pagination", "code-review"] related: [] +fix_commits: ["efff6b65", "ffb3e098"] --- # bug-1903: apiserver GetJobsInfo page_token does not advance: the next page repeats the first @@ -37,17 +38,15 @@ related: [] - 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. +`store/query.go` `findPageTokenIndex` decoded the token with `json.Unmarshal` into `interface{}`, so the token's `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: with no exact match `findPageTokenIndex` returned 0 and every page restarted at row 0 -- the reported repeat-the-first-page (the review fixture's rows are array elements); with a near match it skipped rows instead. `queryControlRowsByJobID`, `FetchJobList` and `GetJobByIDs` page until the token is empty, so the restart case also looped forever on arrays over 1000 elements. ## Fix -Part 1: efff6b65. `findPageTokenIndex` decodes with `json.Decoder.UseNumber()` and converts integers to int64 (floats stay float64). Part 2: not yet fixed. +efff6b65: `findPageTokenIndex` decodes with `json.Decoder.UseNumber()` and converts integers to int64 (floats stay float64), so 63-bit job IDs compare exactly. ffb3e098 adds the handler-level regression test. ## Verification -- Test: (part 1) `TestPaginateRowsArrayElementIDsRoundTripPageToken` in `src/frontend/apiserver/store/query_test.go`; RED before the fix (2452 of 2500 rows), GREEN after +- Test: `TestJobHandler_QueryPagination` in `src/frontend/apiserver/controllers/jobs_handler_test.go` (GetJobsInfo, limit=3, follows `page_token`): RED with efff6b65's parent `store/query.go` (the same three rows returned on every page until the loop guard stopped it), GREEN after; `TestPaginateRowsArrayElementIDsRoundTripPageToken` in `store/query_test.go` (2500 array elements, limit 1000): RED before efff6b65 (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) +- Live: n/a (unit/handler level: the REST handler runs against the real store in the fixture) ## References - Related: bug-1898 (found while fixing it)