Is a <Suspense /> boundary optional on suspense-enabled queries in @urql/next? #3863

This is correct and intentional, and it's the same React-level mechanism you already quoted for useSuspenseQuery, not a coincidence. When urql's suspense mode has no cached result, useQuery throws a promise to trigger the nearest Suspense boundary (that's literally what the hook does internally: if (result == null && suspense) { ...; throw promise }). React's rule for a thrown promise during render is that it propagates up to the nearest <Suspense> ancestor, and if there isn't one, the root of the tree effectively becomes that boundary. During SSR that means the whole render (and therefore the whole HTML response) waits for the promise to resolve before anything is emitted, since there's no fallback anywhere to swap in and stream around.

So without a <Suspense> boundary you get exactly what you saw: no fallback markup, no streaming, full data present in the initial payload even with JS disabled, because the response genuinely didn't start until the query resolved. That's not urql falling back to some default behavior, it's what "no boundary" always means for a component that suspends, urql, React Query, and any other suspense-based data hook all inherit this from React itself.

Given you want exactly that blocking behavior for SEO, you can rely on it, it isn't fragile or unsupported, just undocumented for this specific case. The one thing I'd double check is that you actually want it applied to the whole page rather than a specific section, since omitting <Suspense> anywhere in the tree makes the entire response wait on that query, not just the part of the UI that depends on it. If you later add a second suspense-enabled query elsewhere on the same page without its own boundary, that one will hold up the response too.