Explicit gcTime schedules a GC timer during SSR, retaining the whole render in memory
维护者通常 1 天内回复
评估
- 难度
- 2/5
- 预计耗时
- 1-3 小时
- 新手友好度
- 25/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- node.js, react, typescript
- 领域
- frontend
调研方向
The bug is that an explicit finite gcTime schedules a real timer on the server, while the server default of Infinity does not. Start with the gist's gc-timer-retains-async-context.mjs reproduction and compare pending timers with default and finite. Pull request #12026 already targets this, so review it rather than starting a parallel fix. Done means no garbage-collection timer is scheduled on the server for any gcTime value.
由索引模型根据 Issue 内容生成。
描述
Describe the bug
On the server, a query with an explicit finite gcTime (a regular client-side option) schedules a real setTimeout during SSR. The server default of Infinity is meant to prevent this, but an explicit gcTime bypasses it.
In Node, a pending timer keeps the render's async context (AsyncLocalStorage) alive until it fires. As a result, the entire render stays in memory: the HTML, the RSC payload, and the Request held by react-dom/server.
The timer serves no purpose. The request's QueryClient is discarded together with the response, so there is nothing left to garbage-collect.
Our case: Next.js 16, with a single useQuery({ gcTime: 24h }) in the root provider. Every render left behind a 24-hour timer and about 1.4 MB of retained memory. A heap snapshot of an idle replica showed 272 Request objects and 268 pending timers. Replicas grew until they hit the memory limit and were OOM-killed.
Your minimal, reproducible example
https://gist.github.com/AdzerKI/44081bf1d74a64d43ce651018ce2cba9
Steps to reproduce
- Save gc-timer-retains-async-context.mjs from the gist
- npm i @tanstack/query-core
- node --expose-gc gc-timer-retains-async-context.mjs default
- node --expose-gc gc-timer-retains-async-context.mjs finite
- Compare pendingTimers and rss in the output
Expected behavior
On the server, no garbage-collection timer should be scheduled for any gcTime value, the same as with the server default.
How often does this bug happen?
Every time
Screenshots or Videos
No response
Platform
OS: Linux
Runtime: Node.js 24.21.0 (server-side rendering, no browser involved)
Tanstack Query adapter
react-query
TanStack Query version
v5.104.2
TypeScript version
No response
Additional context
gcTime=default renders=2000 pendingTimers=0 external=2MB rss=119MB
gcTime=60000 renders=2000 pendingTimers=2000 external=1002MB rss=1069MB
- 主要语言
- TypeScript
- 星标
- 50.4k
- 派生
- 4.3k
- 平均合并
- 13 小时 35 分钟
- 30 天内合并 PR
- 442
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
TanStack/query 的其他 Issue
-
QueryClient.isFetching and useIsFetching accept a fetchStatus filter and ignore it可能已有人在做 @Apu-Emdad 于 4 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
solid-query: STRICT_READ_UNTRACKED on Solid 2 — client()/options() read in component body (useMutation, useBaseQuery)可能重新可做 @LeonxLJX 于 44 天前认领，目前没有进行中的 PR。 未关闭
难度 2/5 1-3 小时 新手友好度 84/100
TanStack/query#11358 · 2 条评论 · 1 个 reaction ·
维护者通常 1 天内回复
-
solid-query 6.0.0-rc.5: onCacheEvent throws NotReadyError during a Solid 2 (rc.14+) transition landing可能已有人在做 @UzumakiODZ 于 3 天前认领。 未关闭
难度 4/5 3-5 天 新手友好度 28/100
TanStack/query#12031 · 2 条评论 ·
维护者通常 1 天内回复
-
restoreQueries and persisterGc throw on malformed persisted entries可能已有人在做 @VGontier-cmd 于 12 天前认领。 未关闭
难度 3/5 1-2 天 新手友好度 72/100
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 45/100
TanStack/query#11903 · 1 条评论 ·
维护者通常 1 天内回复
相似的 Issue
-
The inspector never shows the instances field, so scaling out is unreachable可能已有人在做 @Mrkewl 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 76/100
xevrion/breakscale#96 ·
维护者通常 4 天内回复
-
Object parameters lose their structure when resources is enabled可能已有人在做 @asts-top 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 74/100
维护者通常 2 天内回复
-
难度 2/5 1-3 小时 新手友好度 65/100
rossant/awesome-math#199 ·
-
bug
难度 2/5 1-3 小时 新手友好度 88/100
jaegertracing/jaeger-ui#4618 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 70/100
mifi/lossless-cut#3125 ·
维护者通常 1 天内回复