solid-query: EFFECT_RELAY_TEAR on Solid 2 when a query key changes — useBaseQuery relays the result through a version signal written from a render effect #11903

Activity

1. lovrozagar commented on Oct 14, 2026

   

   lovrozagar

   on Oct 14, 2026

   More actions

   Hit this too, and there's a second symptom that comes from the same relay.

   When the key goes back to a key whose cached data is stale (default staleTime: 0), so a refetch happens, and the query sits under <Loading>, Solid also logs ABANDONED_FLIGHTS next to EFFECT_RELAY_TEAR. A router does exactly this when the same page component gets a new param and you then press Back.

   Versions: @tanstack/solid-query 6.0.0-rc.5, @tanstack/query-core 5.101.4, solid-js, @solidjs/signals and @solidjs/web 2.0.0-rc.14, Vite 8.1.4, Chromium 149 dev build.

   import { QueryClient, QueryClientProvider, useQuery } from "@tanstack/solid-query";
   import { createSignal, Loading } from "solid-js";
   import { render } from "@solidjs/web";
   
   const client = new QueryClient();
   let calls = 0;
   const fetcher = (key: string) => new Promise<string>((resolve) => setTimeout(() => resolve(`${key} ${++calls}`), 40));
   const [key, setKey] = createSignal("a");
   
   function Tally() {
   	const query = useQuery(() => ({ queryKey: ["tally", key()], queryFn: ({ queryKey }) => fetcher(String(queryKey[1])) }));
   	return <span id="tally">{query.data}</span>;
   }
   
   render(
   	() => (
   		<QueryClientProvider client={client}>
   			<Loading fallback={<span>loading</span>}>
   				<Tally />
   			</Loading>
   		</QueryClientProvider>
   	),
   	document.getElementById("app")!,
   );
   
   // Three times: setKey("b"), wait 100 ms, setKey("a"), wait 1.5 s.

   Dev console, 2 runs out of 2:

   [ABANDONED_FLIGHTS] "computed" abandoned 3 flights in 1000ms: each was superseded by the next before it landed, so every input asked again and the answers were discarded.
   [EFFECT_RELAY_TEAR] memo "computed" ran twice for one write of "key": once in the flush where "key" changed, and again after effect "effect" relayed it by writing "signal" (3 times so far).
   

   The data ends up right (7 fetches for 1 + 3x2 key changes). The extra reads are flights the next run throws away, because the computed first sees the new key with the old observer result and only settles after the effect writes the new result into the signal.

   A few things I checked:

   • No router or view transition needed. It also happens inside document.startViewTransition with a sync flush().
   • Remounting a stale query without changing its key doesn't warn.
   • Remounting per key avoids it (a keyed <Show> around the component), which is what we do for now.

   So deriving the result in the same flush as the options, as suggested in the issue, should fix both warnings.
2. lovrozagar

   added 2 commits that reference this issue on Oct 14, 2026

   fix(bit-15): every doc slug has a feedback tally, and a failing widge…

   ...

   1b044a5

   refactor(bit-15): the docs feedback tally drops its keyed remount

   ...

   f442302