BaseDataService.fetchInfiniteQuery (query-core v5) appends a later page straight into the infinite cache without checking whether it is already there. Re-requesting a page that is already cached fetches it again and merges it, so the service's cache ends up with duplicated and out of order pages.
The realistic trigger is a refetch. When a UI's stale infinite query rebuilds, query-core re-requests each page through the service, so page 2 is requested again. Verified with createUIQueryClient and an InfiniteQueryObserver against the live behavior: after scrolling to page 2 (service cache params [1, 2]), a refetch leaves the service cache at [2, 1, 2], and each further refetch grows it ([2, 1, 2, 3], and so on).
The UI observers are not directly affected: query-core rebuilds each observer's own result cleanly, so users do not see duplicate items. The impact is on the service's shared cache, which accumulates duplicate and misordered pages over time (unbounded growth across refetches), and a newly hydrating observer can briefly receive the corrupted pages before its own fetch rebuilds them.
This is existing behavior, not a v5 regression. Verified against @tanstack/query-core 4.43.0: v4 also duplicated on every repeat request.
Suggested fix: before merging, if the requested page param is already present, replace that page in place instead of appending or prepending.
Scoped out of the query-core v5 bump (#9712), where Bugbot originally flagged it.
BaseDataService.fetchInfiniteQuery(query-core v5) appends a later page straight into the infinite cache without checking whether it is already there. Re-requesting a page that is already cached fetches it again and merges it, so the service's cache ends up with duplicated and out of order pages.The realistic trigger is a refetch. When a UI's stale infinite query rebuilds, query-core re-requests each page through the service, so page 2 is requested again. Verified with
createUIQueryClientand anInfiniteQueryObserveragainst the live behavior: after scrolling to page 2 (service cache params[1, 2]), a refetch leaves the service cache at[2, 1, 2], and each further refetch grows it ([2, 1, 2, 3], and so on).The UI observers are not directly affected: query-core rebuilds each observer's own result cleanly, so users do not see duplicate items. The impact is on the service's shared cache, which accumulates duplicate and misordered pages over time (unbounded growth across refetches), and a newly hydrating observer can briefly receive the corrupted pages before its own fetch rebuilds them.
This is existing behavior, not a v5 regression. Verified against
@tanstack/query-core4.43.0: v4 also duplicated on every repeat request.Suggested fix: before merging, if the requested page param is already present, replace that page in place instead of appending or prepending.
Scoped out of the query-core v5 bump (#9712), where Bugbot originally flagged it.