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>
timothyandClaude Opus 5
bcbdc9c976