QueryClient.isFetching and useIsFetching accept a fetchStatus filter and ignore it
维护者通常 1 天内回复
评估
- 难度
- 2/5
- 预计耗时
- 1-3 小时
- 新手友好度
- 78/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- react, typescript
调研方向
从 packages/query-core/src/queryClient.ts 开始，issue 指出了其中的展开操作以及 isFetching 对 fetchStatus 的覆盖；然后追踪 useIsFetching 如何传递筛选条件。阅读与 QueryClient.isFetching 和 useIsFetching 相关的测试，并为报告中提到的 paused 和 idle 情况补充覆盖。完成标准是：API 要么遵循该筛选条件，要么在类型中拒绝它，并且行为与文档保持一致。
由索引模型根据 Issue 内容生成。
描述
Describe the bug
QueryFilters has a fetchStatus?: FetchStatus field, and FetchStatus is 'fetching' | 'paused' | 'idle', so isFetching({ fetchStatus: 'paused' }) type-checks. It has no effect: QueryClient.isFetching spreads the filters it is given and then writes its own fetchStatus over them, so the argument is discarded for every value, not only 'paused'.
QueryCache.findAll honours the same filter correctly, which makes the difference easy to miss — the filter works through one entry point and is silently dropped through the other.
Minimal reproduction
import { QueryClient } from '@tanstack/query-core'
const client = new QueryClient()
const queryKey = ['session']
const cache = client.getQueryCache()
const query = cache.build(client, { queryKey, queryFn: async () => 'x' })
query.setState({ fetchStatus: 'paused' })
console.log(cache.find({ queryKey })?.state.fetchStatus) // 'paused'
console.log(cache.findAll({ queryKey, fetchStatus: 'paused' }).length) // 1
console.log(client.isFetching({ queryKey, fetchStatus: 'paused' })) // 0
console.log(client.isFetching({ queryKey, fetchStatus: 'idle' })) // 0
Expected / actual
| call | expected | actual |
|---|---|---|
findAll({ fetchStatus: 'paused' }).length |
1 | 1 |
isFetching({ fetchStatus: 'paused' }) |
1, or a type error | 0 |
isFetching({ fetchStatus: 'idle' }) |
1, or a type error | 0 |
Either outcome would be fine. What is awkward is a public, typed, documented parameter that is accepted and does nothing.
Cause
packages/query-core/src/queryClient.ts:
isFetching(filters) {
return this.#queryCache.findAll({ ...filters, fetchStatus: 'fetching' }).length
}
useIsFetching forwards its filters to this method, so it behaves the same way.
Why it came up
An app that asks "is this query still waiting on the network" wants paused to count: a lookup held because the browser is offline, or because the window is unfocused and the retry is deferred, has not answered yet. Reading it through useIsFetching({ queryKey, fetchStatus: 'paused' }) compiles and quietly answers 0, so the UI treats a waiting query as a settled one. In our case a page showed a "not found" state to someone whose session lookup was merely paused.
The workaround is to subscribe to the cache and use findAll directly, which works but means reimplementing what useIsFetching exists to provide.
Possible resolutions
In rough order of how little they change:
- Type it out — omit
fetchStatusfrom the filters these two accept, so passing it is a compile error, and say in the reference that they count fetching queries only. - Honour it — use the caller's
fetchStatuswhen one is given and default to'fetching'otherwise. This changes behaviour for anyone currently passing a value and relying on it being ignored, which seems unlikely but is a real semver consideration. - Leave the behaviour and document it — note on
useIsFetchingandQueryClient.isFetchingthatfetchStatusis fixed, and point atgetQueryCache().findAllfor other statuses.
Happy to send a PR for whichever you prefer.
Related
- Discussion #6756 proposes a built-in
queryClient.isPaused/useIsPaused, and its example hook uses the same spread-then-override pattern in user code. If that proposal is the intended answer, this is the part of it that bites today — and option 1 or 3 above would stop the current API misleading people in the meantime. - #7559 and #8531 are about
isFetchingreporting the wrong thing for fetching queries; this is narrower, about a filter argument being inert.
Environment
@tanstack/query-core5.104.1- Node 26.11.1, TypeScript 6.0.3
- Reproduced with
query-corealone, so no framework adapter is involved
- 主要语言
- TypeScript
- 星标
- 50.4k
- 派生
- 4.2k
- 平均合并
- 7 小时 37 分钟
- 30 天内合并 PR
- 420
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
TanStack/query 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 72/100
TanStack/query#11930 · 1 条评论 ·
维护者通常 1 天内回复
-
solid-query: STRICT_READ_UNTRACKED on Solid 2 — client()/options() read in component body (useMutation, useBaseQuery)可能重新可做 @LeonxLJX 于 39 天前认领，目前没有进行中的 PR。 未关闭
难度 2/5 1-3 小时 新手友好度 84/100
TanStack/query#11358 · 2 条评论 · 1 个 reaction ·
维护者通常 1 天内回复
-
solid-query: switching the queryClient accessor strands the new client's cache (subscription stays on the old observer)可能已有人在做 @MaNaN1803 于 82 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 84/100
TanStack/query#11106 · 1 条评论 ·
维护者通常 1 天内回复
-
restoreQueries and persisterGc throw on malformed persisted entries可能已有人在做 @VGontier-cmd 于 7 天前认领。 未关闭
难度 3/5 1-2 天 新手友好度 72/100
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 45/100
维护者通常 1 天内回复
相似的 Issue
-
documentation good first issue hacktoberfest help wanted
难度 2/5 1-3 小时 新手友好度 78/100
libredb/libredb-studio#1756 ·
维护者通常 1 天内回复
-
state:triage-needed
难度 2/5 1-3 小时 新手友好度 62/100
维护者通常 1 天内回复
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
难度 1/5 1 小时以内 新手友好度 72/100
lingdojo/kana-dojo#32365 · 1 条评论 · 5 个 reaction ·
维护者通常 1 天内回复
-
friction
难度 2/5 1-3 小时 新手友好度 72/100
kentcdodds/kody#3706 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
copperheadhq/copperhead#378 ·
维护者通常 1 天内回复