fix(634): page the rerun-collection picker to completeness #645

Merged

timothy merged 3 commits from fix/634-rerun-picker-paging into main 2026-07-26 12:20:28 +02:00

Conversation 1 Commits 3 Files Changed 2

+81 -11

3 Commits

Author	SHA1	Message	Date
timothy	f9380eb494	fix(634): stop the #616 guard from asserting an invariant the fix violates ... Cold review finding. The #616 regression test looped over EVERY rerun-collection request asserting pageNum === '0'. That was right when exactly one request was ever issued, but since this branch the loader legitimately walks pageNum 1, 2, … to page to completeness — so the assertion now describes something the correct code does not do. It passes today only because the shared fixture's totalCount fits in a single page. Raising that default would have failed the #616 test with a "picker requested page 1" signal for what is proper paging, sending the next reader after a defect that isn't there. Narrow it to the first request, which is the offset #616 actually cared about. Also corrects the new comment's history: the `pageNum: 1` it describes is pre-#616, not the previous commit.	2026-07-26 11:16:20 +02:00
timothy	f9164b71af	fix(634): keep the 0-based lesson at the call site ... The #616 comment this call site carried recorded WHY it reads `pageNum: 0` — a previous version passed 1 and skipped the whole first page. Rewriting the call for #634 dropped it. Restore it next to the new paging loop, which also starts its follow-up requests at 1 and is only correct because the first page is 0.	2026-07-26 11:11:33 +02:00
timothyandClaude Opus 5	bcbdc9c976	fix(634): page the rerun-collection picker to completeness ... SchedulesScreen loaded the rerun-collection picker with getRerunCollections({ pageNum: 0, pageSize: 1000 }). The server (RerunCollectionController) clamps pageSize via Math.Clamp(pageSize, 1, MaxPageSize) with MaxPageSize=100, so the request was silently served only the first 100 rows regardless of what was asked for. With >100 rerun collections, the picker omitted the rest with no error and no truncation indicator — a schedule item couldn't be pointed at a rerun collection past the 100th. Fix: page the client to completeness against totalCount, mirroring CollectionsScreen.enterReorder (fetch page 0, keep requesting subsequent pages while accumulated < totalCount, break early if a page returns zero rows to guard against a non-terminating loop on a server-side anomaly). Per api.search-allitems-paging precedent, the client pages rather than raising the server's MaxPageSize cap. Audited the other loadPickerData fetches (getPlaylistGroups, getWatermarks, getGraphicsElements, getLanguages, getFillerPresetsByKind): their endpoints return a plain, unpaged array server-side with no pageNum/pageSize params and no clamp, so they aren't subject to the same silent-truncation defect and don't need the same treatment. Adds a vitest case pinning the exact expected option set (150 rerun collections across two pages) rather than a non-empty/truthy check. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 11:01:53 +02:00