fix(query-core): fall back to query's own staleTime in isStatic() when no observers exist - #11195
fix(query-core): fall back to query's own staleTime in isStatic() when no observers exist#11195waterWang wants to merge 1 commit into
Conversation
…n no observers exist
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan includes up to 10 reviews per rolling hour; 9 remain after this review. 📝 WalkthroughWalkthrough
ChangesStatic stale-time handling
Estimated code review effort: 2 (Simple) | ~5 minutes Merge Risk: ⚪ Minimal · up to The change restores the documented static stale-time behavior for unobserved queries without introducing any actionable merge-blocking risk; it is merge-ready after normal checks and review. Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
fix(query-core): fall back to query's own staleTime in isStatic() when no observers exist
Description
staleTime: 'static'stops being honoured as soon as a query has no observers, sorefetchQueries({ type: 'all' })andinvalidateQueries({ refetchType: 'all' })re-run thequeryFnfor queries that the docs promise will never refetch.Query.isStatic()derives 'static' only from live observers. When there are no observers, it returnsfalse, contradicting the documented behaviour:The neighbouring
isDisabled()method already handles the no-observer case correctly with an explicit fallback. This fix mirrors that pattern.Changes
packages/query-core/src/query.ts: WhenisStatic()has no observers, fall back to the query's ownstaleTimeoption instead of returningfalse.Fix details
The
as anycast is needed becausestaleTimeis declared onQueryObserverOptionsandFetchQueryOptions, not on the baseQueryOptionsinterface — but the value is always present at runtime sinceQuery.setOptionsstores the full merged options object.Test results
The fix is verified against the issue author's test cases:
prefetchQuery, never observed → calls=1fetchQuery, never observed → calls=1staleTime: Infinity→ calls=2 (still invalidatable, per the documented distinction)Full
packages/query-coresuite: 554 passed.Fixes #11190
Summary by CodeRabbit