Repository navigation
Conversation
…s queries still fetch fetchOptimistic builds the query from the observer's options but then calls query.fetch() without them. QueryCache.build returns an existing query without applying options, so a query that was rebuilt without a queryFn - by broadcastQueryClient from a cross-tab message, or hydrated - throws Missing queryFn when a suspending observer fetches it before any observer has attached: the fallback at the top of fetch() only looks at already-attached observers, and there are none yet in this path. Reported through query-broadcast-client-experimental: when a query is removed and re-added cross-tab, the rebuilt query stays without a queryFn if the other tab's fetch never succeeds, and a mounted useSuspenseQuery crashes with Missing queryFn on its next optimistic fetch instead of fetching with its own options. The regression test reproduces that sequence: observer bound -> query removed -> rebuilt from key+hash only -> fetchOptimistic. It fails with Missing queryFn before this change and succeeds after. Full queryObserver suite (76) and broadcast client suite (13) pass. Fixes TanStack#12129
The server default of gcTime: Infinity prevents gc timers during SSR, but an explicit finite gcTime on a query or mutation bypassed it and scheduled a real setTimeout. On the server the timer serves no purpose - a request-scoped QueryClient is discarded with the response - but a pending timer keeps the render's async context alive until it fires, retaining the HTML, the RSC payload and the Request held by react-dom/server. With useQuery({ gcTime: 24h }) in a root provider, every render of a Next.js app left behind a 24-hour timer and ~1.4MB of retained memory until replicas were OOM-killed.
scheduleGc now returns early in server environments. Client behavior is unchanged.
Fixes TanStack#12025
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to
|
| Check name | Status | Explanation | Resolution |
|---|---|---|---|
| Out of Scope Changes check |  |
The change to QueryObserver.fetchOptimistic and its test address fetching a rebuilt query that has no queryFn. This behavior is unrelated to issue #12025, which concerns server-side GC timers and … |
Remove the queryObserver.ts change and its regression test, or move them to a separate pull request with the relevant linked issue. |
-
Check name Status Explanation Title check The title clearly and concisely summarizes the primary change: preventing garbage-collection timers on the server. Description check The description clearly explains the problem, motivation, implementation, regression test, test results, and linked issue. It does not reproduce the template headings or checklist, but it provides the… Linked Issues check Issue #12025requires no GC timer on the server for anygcTime.Removable.scheduleGcnow clears an existing timeout and returns whenisServerEnvironment()is true. This covers the shared removab…Docstring Coverage Docstring check was indeterminate for this PR — some files could not be analyzed in time. Not blocking. Full details: Description check
-
Explanation
The description clearly explains the problem, motivation, implementation, regression test, test results, and linked issue. It does not reproduce the template headings or checklist, but it provides the required substantive information and is mostly complete.
Full details: Linked Issues check
-
Explanation
Issue
#12025requires no GC timer on the server for anygcTime.Removable.scheduleGcnow clears an existing timeout and returns whenisServerEnvironment()is true. This covers the shared removable path used by queries and mutations. The new regression test uses finitegcTime: 1000, verifies zero timers, advances time, and verifies that the query remains cached.
-
Full details: Out of Scope Changes check
-
Explanation
The change to
QueryObserver.fetchOptimisticand its test address fetching a rebuilt query that has noqueryFn. This behavior is unrelated to issue#12025, which concerns server-side GC timers and retained SSR context. The current PR description also does not identify this second objective.Resolution
Remove the
queryObserver.tschange and its regression test, or move them to a separate pull request with the relevant linked issue.
- Fix all pre-merge checks with AI
✨ Finishing Touches
-
🧪 Generate unit tests (beta)
-
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
Comment @coderabbitai help to get the list of available commands.
This branch has not been deployed
1 participant
On the server, a query or mutation with an explicit finite
gcTimeschedules a realsetTimeoutduring SSR: the server default ofInfinityis applied throughupdateGcTime's fallback, which an explicit value bypasses. The timer serves no purpose - a request-scopedQueryClientis discarded together with the response - but a pending timer keeps the render's async context (AsyncLocalStorage) alive until it fires, retaining the HTML, the RSC payload, and theRequestheld byreact-dom/server.Reported in #12025 with a real-world case: a single
useQuery({ gcTime: 24h })in a Next.js root provider left a 24-hour timer and ~1.4 MB of retained memory behind on every render; an idle replica accumulated 272Requestobjects and 268 pending timers before being OOM-killed.scheduleGcnow returns early in server environments, so no gc timer is scheduled for anygcTimevalue - the same behavior as the server default. Client behavior is unchanged (the server check is the existingenvironmentManagerdetection, already used for thegcTimefallback and retry defaults).Regression test: with the server environment forced, a finished query with
gcTime: 1000must leavevi.getTimerCount()at 0 and still be in the cache after advancing past the gcTime. Verified to fail before (expected 1 to be +0) and pass after. Full query + mutation suites pass (81/81).Fixes #12025
Summary by CodeRabbit