solid-query: every observer notification cycles the internal resource, re-triggering ancestor Suspense and detaching live DOM (focus/scroll loss)

[PyrozhenkoSerhii]

solid-query: every observer notification cycles the internal resource, re-triggering ancestor Suspense and detaching live DOM (focus/scroll loss)

Describe the bug

createBaseQuery's client subscriber calls refetch() on its internal Solid resource for every observer notification:

const createClientSubscriber = () => {
 const obs = observer();
 return obs.subscribe((result) => {
 observerResult = result;
 queueMicrotask(() => {
 if (unsubscribe) {
 refetch();
 }
 });
 });
};

refetch() runs the resource fetcher, which resolves synchronously when the query already has data — but the returned promise is a plain native promise, so Solid's createResource.load() still sets pr, transitions to "refreshing", and fires trigger(). Any Suspense-tracking computation previously installed by read() re-runs, sees pr set, and increments the nearest <Suspense> boundary, which detaches its children's DOM until the microtask resolves.

The result: on notifications that should be invisible — most notably the staleTime bookkeeping flip (fresh → stale, no fetch, no data change) and background refetch completions — the entire subtree under the Suspense boundary is detached and reattached within one task. The same DOM nodes come back, so nothing looks different, but:

• the focused input is blurred (typing users lose focus),
• scrollTop of scroll containers is reset,
• selection is lost.

With an app-level <Suspense> around the router (the common Solid pattern for lazy() routes), this detaches the whole app, once per query, in a burst exactly staleTime after page load.

The permanent-tracker window

The Suspense-tracking computations that fire are installed by read() and normally get disposed when the reading computation re-runs on data arrival. But there's a window that makes them permanent: when an observer is created for a query whose data is already in the cache (second observer, remount, route return), the resource's fetcher resolves synchronously but resolved is still false for one microtask. A .data read during that window goes through latest → read() and installs a tracker owned by a computation that never re-runs (the store write that follows doesn't change .data's reference). From then on, every notification on that query detaches the boundary.

Your minimal example

Reproduction (SolidJS 1.9.12, @tanstack/solid-query 5.99.2, also present in 5.101.2 source):

const client = new QueryClient({ defaultOptions: { queries: { staleTime: 1000 } } });
client.setQueryData(['probe'], 'cached'); // cache-warm → permanent tracker window

const Content = () => {
 const query = createQuery(() => ({ queryKey: ['probe'], queryFn: () => 'fresh' }));
 return (
 <div>
 <span>{query.data}</span>
 <input />
 </div>
 );
};

render(() => (
 <QueryClientProvider client={client}>
 <Suspense fallback={<div>loading…</div>}>
 <Content />
 </Suspense>
 </QueryClientProvider>
));

// focus the <input>, wait ~1s (staleTime flip, no fetch, no data change):
// → Suspense detaches/reattaches the subtree, input loses focus.
// A MutationObserver on the container sees the removal; document.activeElement === body.

Expected behavior

A notification that carries an already-settled result (data present, not loading, not errored) should not re-suspend anything. The store update alone is enough — setStateWithReconciliation is what the resource's storage setter calls anyway.

Suggested fix

Only cycle the resource when it must actually (re)enter a loading or error state; write settled results straight to the store:

queueMicrotask(() => {
 if (!unsubscribe) return;
 if (resolver || result.isLoading || result.isError) {
 refetch(); // initial resolution / genuine load / error → keep suspense + throw semantics
 } else {
 setStateWithReconciliation(result);
 }
});

We've been running this as a pnpm patch in production: initial suspense, error boundaries, optimistic updates, invalidation-driven refetches, and query-key changes all behave identically, while the idle detach storms (and the focus/scroll loss they caused) are gone.

Platform

• OS: any (reproduced Windows/Chrome, jsdom)
• solid-js 1.9.12
• @tanstack/solid-query 5.99.2 (same subscriber code in 5.101.2)

Tanstack Query adapter

• solid-query

[pupuking723]

I'd like to take a look at this if maintainers are open to a PR. I'll start by reproducing the cached-data + staleTime notification case and keep the change limited to avoiding a resource refetch for already-settled observer results, so initial suspense, error, and query-key transitions keep their current behavior.