Repository navigation
Server-side gcTime schedules a GC timer that pins the whole SSR async context #11320
Description
Activity
Could this be the same issue I'm experiencing?
The issue is that, the queryClient data loaded on the server never gets garbage collected.
For example, data loaded during a fresh visit or page reload seems to never get garbage collected, while data loaded through normal in-app navigation is garbage collected as expected.Depends on where you are looking.
This issue is about the server process: with a finite gcTime the SSR render schedules a Node timer, and that timer pins the render context, so RSS keeps growing across requests. In the browser cache, hydrated queries are collected like any other once nothing observes them.
So — do you set a finite gcTime anywhere, and is the growth in Node RSS or in the browser heap? If it is the browser heap, it is something else.
I think I found the bug.
The gcTime falls back to default 30_000 ms on page refresh and fresh app visit.Edit: It happens specifically when the configured query option gcTime is less than the default gcTime. If it's higher than default, it behave normally.
My query option setup
infiniteQueryOptions({ queryKey: [...postQueries.all(), 'feed', params], queryFn: ({ pageParam }) => { return get_posts_feed_fn({ data: { cursor: pageParam, ...params } }) }, initialPageParam: undefined as string | undefined, getNextPageParam: (lastPage) => lastPage.meta.nextCursor ?? undefined, select: selectFeed, staleTime: Infinity, gcTime: 5_000, }),
Hard refresh / Fresh application visit. (30_000 ms)
Normal in-app page navigation via
<Link />or navigate (5_000 ms, match with my query option config)
That is a different one, worth its own issue.
hydrate()builds the query fromdefaultOptions.hydrate.queriesplusclient.defaultQueryOptions()— it never sees the options you pass toinfiniteQueryOptions, so the hydrated query starts with the client defaultgcTime. When your component then observes it,setOptionsgoes throughupdateGcTime, which isthis.gcTime = Math.max(this.gcTime || 0, newGcTime ?? 3e5): a smaller per-querygcTimecan never win over what hydration already put there. On in-app navigation there is no hydrated query, the observer builds it, and your 5s applies — which is exactly the split you are seeing.This issue is about the server scheduling the GC timer at all, and the timer pinning the render context.
- added a commit that references this issue
on Sep 23, 2026
Describe the bug
On the server
updateGcTimefalls back toInfinity, so by default no GC timer is scheduled and the per-requestQueryClientis simply dropped with the response. As soon as a query passes an explicit finitegcTime— a normal client-side option, e.g. "keep the platform limits for a day" — that fallback is bypassed andscheduleGc()schedules a realsetTimeoutduring server rendering.A Node timer captures the async context it was created in. A timer created inside an SSR render therefore keeps that render's
AsyncLocalStoragestore alive for the wholegcTime— and with it everything the framework stores there: the work store, thereact-dom/serverRequest, the produced HTML and the RSC payload. The timer can never do anything useful either: the client it would clean up is unreachable long before it fires.In our Next.js 16 App Router app one
useQuery({ gcTime: 24h })sits in the root provider, so every page render left one pending 24h timer and ~1.4 MB retained. A heap snapshot of an idle replica showed 272 livereact-dom/serverRequestobjects and 268 pending timers, retained throughTimeout → [kAsyncContextFrame] → AsyncContextFrame → … → Query. Replicas grew to the pod memory limit and were OOM-killed.Your minimal, reproducible example
https://github.com/proxy/gist.github.com/AdzerKI/44081bf1d74a64d43ce651018ce2cba9
Steps to reproduce
The script simulates 2000 SSR renders. Each render runs inside an
AsyncLocalStoragestore holding a 512 KB payload, creates a per-requestQueryClientand builds one query. All references are dropped andglobal.gc()is called twice before measuring.Expected behavior
The server never schedules a GC timer, whatever
gcTimethe query asks for — the same outcome theisServer ? Infinitydefault already produces. The render context is released as soon as the response is done.How often does this bug happen?
Every time
Platform
Tanstack Query adapter
react-query
TanStack Query version
v5.101.0 (
@tanstack/query-core)TypeScript version
v6.0.3
Additional context
Suggested fix — make
scheduleGc()a no-op on the server:This keeps the
gcTimevalue itself (nothing else reads it on the server) and matches what the server default already does. Long-lived Node processes that do want garbage collection already have an escape hatch:environmentManager.setIsServer(() => false).Happy to open a PR with this and a test.