Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

HydrationBoundary ignores/skips server-prefetched query when a parent useQuery with same key is rendered before child useSuspenseQuery

Offen
  • Stimmt etwas nicht?
#10,145 4 Kommentare 1 Reaktion 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@mgarcialeniolabs arbeitet bereits daran.

Seit 27.8.2026.

  • #10159 von @ColemanDunn — ohne Merge geschlossen
  • #10535 von @byungsker — ohne Merge geschlossen
  • #11310 von @yogesh968 — ohne Merge geschlossen
  • #11318 von @mgarcialeniolabs — offen

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
52/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
react, typescript
Bereich
frontend

Rechercherichtung

Beginne mit der verknüpften CodeSandbox-Reproduktion und verfolge das Verhalten von HydrationBoundary im Umfeld von useQuery im Parent und useSuspenseQuery im Child anhand des im Bericht beschriebenen Ablaufs in app/(dashboard)/todos/[todoId]/layout.tsx oder page.tsx. Vergleiche die Zustände von serverseitigem Prefetching, Dehydration und Hydration; abgeschlossen ist die Aufgabe, wenn der prefetched key für das Child verfügbar bleibt, ohne eine doppelte SSR-Anfrage oder einen client-request guard error zu verursachen.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Describe the bug

If a useQuery is rendered before a HydrationBouhndary, hydrations for that key will be skipped despite the fact that the useQuery would have not fetched in the first place.

In our case we have a prefetch where we pass the dehydrated queryClient to a HydrationBoundary. But there is a useQuery using the same key as the prefetched query above the hydration boundary that (in some global component higher up) gets rendered. The hydration boundary skips this hydration and the child components of the HydrationBoundary that have useSuspenseQuery for that key still run their queries in SSR.

Small example:

function Page({ params }) {
  const queryClient = getQueryClient();
  void queryClient.prefetchQuery(
    buildTodoQueryOptions(params.todoId, makeServerRequest),
  );

  return (
    <>
      <SomeHeaderComponent /> {/* a `useQuery` lives in here */}
      <HydrationBoundary state={dehydrate(queryClient)}>
        <MyChildComponent /> {/* a `useSuspenseQuery` lives in here and fires despite the above prefetch */}       
      </HydrationBoundary>
    </>
  );
}

Also, in our particular case this triggers a guard we have to ensure we do not client fetch on the server during SSR. This also means the request is being duplicated and firing twice (in our prefetch and during SSR, which should have been skipped)

Flow (all on the server):

  1. Parent/route boundary prefetches the detail query todoId on the server.
  2. A higher component in layout/header renders a useQuery with the key todoId.
  3. Pass the dehydrated and prefetched queryClient to a HydrationBoundary lower than the useQuery.
  4. The HydrationBoundary` skips this key and does not hydrate the prefetched query as expected.
  5. Child useSuspenseQuery then attempts a fetch with client requestor during SSR and hits the guard error.
Repro

Server prefetch at detail layout/page:

// In app/(dashboard)/todos/[todoId]/layout.tsx or page.tsx
function Page({ params }) {
const queryClient = getQueryClient();
void queryClient.prefetchQuery(buildTodoQueryOptions(todoId, makeServerRequest));
return <HydrationBoundary state={dehydrate(queryClient)}>{children}</HydrationBoundary>;
}

Global/header client component that also reads URL todoId (lives OUTSIDE/above the above layout.tsx)

"use client";

import { useQuery, useParams } from "@tanstack/react-query";

function TodoHeaderMenu() {
  const params = useParams();
  const todoId = typeof params.todoId === "string" ? params.todoId : "";

  const { data: todo } = useQuery({
    ...buildTodoQueryOptions(todoId),
    enabled: Boolean(todoId),
  });

  return <span>{todo?.title}</span>;
}

Child detail component:

"use client";

function TodoPage({ todoId }: { todoId: string }) {
  const { data: todo } = useSuspenseQuery(buildTodoQueryOptions(todoId));
  return <TodoDetails todo={todo} />;
}

buildTodoQueryOptions defaults to client requestor. Client-request guard throws:

if (typeof window === "undefined") {
  throw new Error(
    "Warning, aborting SSR. You attempted to fetch from the server with clientRequest."
  );
}

AI disclosure: I had codex help me with the quick repro.

Questions
  1. Is this current behavior expected?
  2. Should hydration logic be changed to only skip queries that are fetching (aka don't skip useQueries that fill the cache key on the server but do not initiate filling the value on the server)
Your minimal, reproducible example

https://codesandbox.io/p/devbox/pr7c4g

Steps to reproduce

The home page on that will bring up the error in the next dev error popup

Expected behavior

I would expect a useQuery in a higher component with the same key to not STOP the server fetch/hydration given useQuery would not trigger the client request guard like useSuspenseQuery does. useQuery does not start the queryFn on the server, so it should not stop useSuspenseQueries that CAN imo.

This also comes with the additional problem that because of the useQuery, the useSuspenseQuery is firing again, ruining deduplication.

How often does this bug happen?

Every time

Screenshots or Videos

No response

Platform

macOS

Chromium

next: 16.1.1

Tanstack Query adapter

react-query

TanStack Query version

5.90.21

TypeScript version

No response

Additional context

I can technically gate the useQuery in the parent component with something like

const isDealQueryReady = !!(
    state &&
    state.data !== undefined &&
    state.status !== "pending" &&
    state.fetchStatus !== "fetching"
  )

//and then 
if (!isDealQueryReady) {
  return null;
}

//...

//...`useQuery`

and then I do not get the error but that is obnoxious.

Vorherrschende Sprache
TypeScript
Sterne
50.4k
Forks
4.3k
Ø Merge
12 Std. 18 Min.
Gemergte PRs (30 T.)
488

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus TanStack/query

Alle Issues in TanStack/query

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.