The error will be redacted in production builds

[yrnana]

I'm using nextjs 14 app router and tanstack query 5.40+ (no persist)

https://tanstack.com/query/v5/docs/framework/react/guides/advanced-ssr#streaming-with-server-components
I'm trying to use no-await prefetch method, but whenever I get a error from server component, I get this error message and can't get original error object anywhere.

console.error(
            `A query that was dehydrated as pending ended up rejecting. [${query.queryHash}]: ${error}; The error will be redacted in production builds`,
          )

I found comments about reason for redacted error (retry in client component),
however there are also errors that do not need to be retried because they will failed anyway (like auth token expired)

So isn't there a way to handle error content before dehydrate query.promise?
Thank you!

[TkDodo]

I think you can dehydrate the query client, which just puts it into an object. Then, you can map over the queries and transform promise yourself. Something like:

queryClient.prefetchQuery({
  queryKey: ['posts'],
  queryFn: getPosts,
})

const dehydrated = dehydrate(queryClient)

dehydrated.queries = dehydrated.queries.map(query => ...)

<HydrationBoundary state={dehydrate(queryClient)}>

[focux]

I would have expected that you would catch and redact the errors that you don't want to show yourself.

In my case, I'm calling an API, and I would love to handle the status code errors returned by the API, especially now that next.js has functions to show especial pages depending on the error like unauthenticated()‘, forbidden()‘, etc.

Also, not sure if it has been others experience but the error boundary is not catching the error either.

[Ephem]

I meant to look at this last week but got sidetracked. I think there are several pains here. First, I think we'll want to make it configurable how to handle errors in promises being de/rehydrated in general. I think redacting is a good default, but you should be able to opt in to not redacting if you are using a framework like Next that does it for you. It should also be possible to silence the errors on the server side since it litters logs etc.

The second issue is you might want to do this on a query-level. So even if you are redacting errors by default, you might want to catch and transform the error into something that is not redacted for specific queries. Maybe even some way of avoiding retries, but I'm not sure we need to do something specific about that one. I think if you can transform the error yourself, you could use the function form of retries to accomplish this in userland.

I haven't gotten as far as figuring out the API-details for this yet though, but I'm very much dealing with the same pains on pretty much a daily basis, so it's at the top of my OSS-priority list. 😅

[stakbucks]

@focux @yrnana For stopgap, I just patched the dehydrate code from here. Which is literally the same except that it doesn't throw redact Error when query fails.

function defaultTransformerFn(data: any): any {
  return data;
}

function dehydrateQuery(query: Query, serializeData: TransformerFn): DehydratedQuery {
  return {
    state: {
      ...query.state,
      ...(query.state.data !== undefined && {
        data: serializeData(query.state.data)
      })
    },
    queryKey: query.queryKey,
    queryHash: query.queryHash,
    ...(query.state.status === 'pending' && {
      promise: query.promise?.then(serializeData)
    }),
    ...(query.meta && { meta: query.meta })
  };
}

function dehydrateMutation(mutation: Mutation): DehydratedMutation {
  return {
    mutationKey: mutation.options.mutationKey,
    state: mutation.state,
    ...(mutation.options.scope && { scope: mutation.options.scope }),
    ...(mutation.meta && { meta: mutation.meta })
  };
}

export function dehydrate(client: QueryClient, options: DehydrateOptions = {}): DehydratedState {
  const filterMutation =
    options.shouldDehydrateMutation ??
    client.getDefaultOptions().dehydrate?.shouldDehydrateMutation ??
    defaultShouldDehydrateMutation;

  const mutations = client
    .getMutationCache()
    .getAll()
    .flatMap(mutation => (filterMutation(mutation) ? [dehydrateMutation(mutation)] : []));

  const filterQuery =
    options.shouldDehydrateQuery ??
    client.getDefaultOptions().dehydrate?.shouldDehydrateQuery ??
    defaultShouldDehydrateQuery;

  const serializeData =
    options.serializeData ??
    client.getDefaultOptions().dehydrate?.serializeData ??
    defaultTransformerFn;

  const queries = client
    .getQueryCache()
    .getAll()
    .flatMap(query => (filterQuery(query) ? [dehydrateQuery(query, serializeData)] : []));

  return { mutations, queries };
}

[focux]

@stakbucks Great! Will give it a try, thank you.

@Ephem @TkDodo Not sure if this is the right thread to ask, but another QoL improvement would be making the suspense query dehydrate/hydrate the headers that were sent on the initial/prefetched query.

Right now, if I prefetch a query on a server components, I need to pass down the headers (cookie headers mostly) to the component that is calling the useSuspenseQuery, otherwise, it throws an authorization error, I guess that is because of the SSR pass of the suspense query, although I would've expect that if the query was initiated on the server, all the headers would be also dehydrated/hydrated.

[phryneas]

In Apollo Client, we handle it like this:

• errors during SSR of client components will cause a rerender in the browser anyways -> we transport nothing, the query will be re-triggered in the browser, if it errors there, too, the user will see an error boundary.
• when transporting data that was fetched in RSC to prime a Client Component cache:
  • the special class of "graphql errors" will be transported over
  • any error in the link chain (e.g. when calling fetch will not be transported over. The query will be retried in the browser, if it errors there, too, the user will see an error boundary.

Generally, the concept of "will retry in the browser, if it errors there, too, the user will see an error boundary." is how React itself handles these kinds of errors, so we try to stay in line with that.
Only exception here are errors encoded within the query response, as these are meant to be sent to the browser anyways.
Of course, you don't have that specific "class" as you don't only support GraphQL, but maybe you could allow for a callback that lets the user decide if a specific error can be transported over or not?