How to make prefetched queries don't retry on error?

[dBianchii]

I would like to understand how I can:

1. Prefetch a query in a RSC
2. If that query fails, I would like to not run any operations whatsoever. I would like for any client-side mounted queries to not trigger refetches at all

const ApplicationLayout = ({
	children,
}: LayoutProps<"/app"> | LayoutProps<"/admin">) => {

	prefetch([
		trpc.admin.me.queryOptions(undefined, {
			retry: false,
		}),
	]);

	return (
		<HydrateClient> // Btw HydrateClient is just this: https://github.com/t3-oss/create-t3-turbo/blob/main/apps/nextjs/src/trpc/server.tsx#L35-L42
			{children}
		</HydrateClient>
	);
};

export default ApplicationLayout;

And then I have a hook that is used in almost ALL pages (except for the auth page for example):

"use client"

export const useAdminUserData = () => {
	const trpc = useTRPC();

	const query = useQuery(
		trpc.admin.me.queryOptions(undefined, {
			enabled: false, //Notice the enabled:false and the retry: false
			retry: false
		}),
	);
	
	//...More implementation here. (I have custom logic to manually refetch this data)
	return query;	
}

I want to have this pattern for the sole reason that pretty much 100% of the pages need the admin.me query. However, if you are not logged in, then this query fails. I CANNOT conditionally call this based on authentication because I am using Next.JS cacheComponents, and I don't want to make my entire application (from this layout) be under a <Suspense> boundary.

This setup with retry: false in the queryOptions is not working, and the client-side query client ALWAYS is causing additional retries on the client side, which I do not want.

This is what happens in the auth page:

If I remove the prefetch in the RSC, then there's no fetching happening at all and no errors/no retries. (But this is not what I want since I want the prefetch, obviously)

[TkDodo]

it seems like you’re making use of streaming by sending the promise from the server to the client. With this approach, the query on the client picks up the promise from the server. If it fails, retries apply.

the options taken into account here are the ones from when the query was created via hydration, not the one from useQuery since we can’t know if and whene the query that gets sent from the server will be picked up on the client, and we also don’t know which options will be applied then.

to set those options (retry: false is likely the one that matters) you can either set a global default on the queryClient, or set it for hydration only on the HydrationBoundary with:

<HydrationBounary
  state={dehydrate(queryClient)}
  options={{ defaultOptions: { queries: { retry: false } } }}
/>

[dBianchii]

That is great! Exactly what I wanted and seems to work.

Now, there are only two missing things that I need to get this to work:

1. It seems that I am getting this in the layout file:

Why is dehydrate using date.now? (Again, I do not want to use Suspense for the entire layout/app here)

2. I am getting these warnings all the time in my dev console. Is there a way to disable them? It says that the errors will be discarded in production builds.

3. I think this one is more manageable /I can find hacks around. But basically, my code has a useEffect:

	const query = useQuery(
		trpc.admin.me.queryOptions(undefined, {
			enabled: false,
		}),
	);

	useEffect(() => {
		if (query.error) {
			toast.error("Failed to load admin user data");
		}
	}, [query.error]);

The effect is being ran and toast.error is still getting called when the query errors. Is there a way for me to prevent this happening only for errors that were thrown from that prefetch? (I can do hacks like checking if it is an UNAUTHORIZED error before calling toast. but just wondering if there is a better setup for me here)

[TkDodo]

Why is dehydrate using date.now?

because we send a dehydratedAt timestamp down:

query/packages/query-core/src/hydration.ts

Line 107 in b4cd121

dehydratedAt: Date.now(),

I am getting these warnings all the time in my dev console. Is there a way to disable them? It says that the errors will be discarded in production builds.

you can set shouldRedactErrors: false to not redact them, but then the server side error incl. details might be visible on the client.