solid-query: STRICT_READ_UNTRACKED on Solid 2 — client()/options() read in component body (useMutation, useBaseQuery)
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 50.3k
- Forks
- 4.2k
- Avg merge
- 18h 25m
- Merged PRs (30d)
- 200
Description
Describe the bug
With Solid 2 (solid-js@2.0.0-rc.4) and @tanstack/solid-query@6.0.0-rc.1, every component that calls useMutation (and useQuery) logs a reactivity diagnostic on mount:
[STRICT_READ_UNTRACKED] Reactive value read directly in <UnitCard> will not update.
Move it into a tracking scope (JSX, a memo, or an effect's compute function).
[STRICT_READ_UNTRACKED] repair guide: node_modules/solid-js/skills/reactivity-diagnostics/SKILL.md
Solid 2 ships these diagnostics in dev builds, and they are meant to be actionable: the console is expected to stay clean. Right now a single screen with a handful of mutations produces dozens of them, which drowns out the diagnostics that are about application code.
Cause
The hooks read memos directly in the component body, outside any tracking scope.
packages/solid-query/src/useMutation.ts:
const client = createMemo(() => resolveClient())
const observer = new MutationObserver(client(), options()) // ← read in component body
packages/solid-query/src/useBaseQuery.ts does the same when it creates its observer:
const initialOptions = defaultedOptions()
const [observer, setObserver] = createSignal(
new Observer(client(), defaultedOptions()), // ← read in component body
)
Both reads are intentional one-shot initialisations, so the value genuinely does not need to be tracked — which is exactly the case Solid's untrack exists for. Under Solid 1 this was silent; Solid 2 reports it.
Your minimal, reproducible example
Any component calling useMutation reproduces it. The official Solid 2 fullstack template does it out of the box:
https://github.com/solidjs/templates/tree/main/solid-v2/fullstack-tanstack
src/routes/users.$id.tsx calls useMutation; open the page with a dev build of solid-js@2 and the diagnostic appears on every mount.
Steps to reproduce
- Use
solid-js@2.0.0-rc.4with@tanstack/solid-query@6.0.0-rc.1. - Render any component that calls
useMutation(oruseQuery). - Watch the browser console on mount.
Expected behavior
No reactivity diagnostics from library code — the initial reads of client() / options() are untracked by design and should say so.
Suggested fix
Wrap the initialisation reads in untrack(...), or move observer creation into a createRenderEffect / memo. A related Solid-specific fix was already made in #10445 (useQueryClient running inside createMemo).
Platform
@tanstack/solid-query6.0.0-rc.1 (latestrcon npm as of 2026-09-01)solid-js2.0.0-rc.4- Chromium 141, macOS
Note
Not filing a PR because I did not want to guess which of the two shapes (untrack vs. deferred observer creation) you prefer for v6 — happy to send one either way.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in packages/solid-query/src/useMutation.ts and packages/solid-query/src/useBaseQuery.ts, where client() and options() are read during observer initialization. Reproduce with Solid 2 and the provided component scenario, then choose the intended untracked or deferred initialization approach. Done means mounting components using useMutation or useQuery no longer produces library STRICT_READ_UNTRACKED diagnostics.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- frontend
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 84/100