useSuspenseQuery do not throw when a "refetch" throws?

[patricklafrance]

Hello!

I noticed that when using useSuspenseQuery, if the fetch request fails, an error is thrown. However, on a refetch, if the fetch request fails, it doesn't seems to throw. It does returns the error through the error prop though.

So I could do:

const { data, error } = useSuspenseQuery(...);

if (error) {
   throw error;
}

But I was wondering if there's a way to configure this behavior with the default options of a QueryClient ?

Thank you,

Patrick

[TkDodo]

However, on a refetch, if the fetch request fails, it doesn't seems to throw.

If you have data in the cache, even if its stale data, we will still render the component and not throw to the error boundary. That's on purpose because we believe stale data is better than no data - you get the same behaviour with useQuery.

throwing the error if it exists like shown is the best way if you really want that behaviour.

[patricklafrance]

Hey @TkDodo thanks for the quick reply 🙏🏻

I could use your advices on how we can solve our use case.

In one of our product, a user permissions (or even the feature flags of the product) could change at anytime. When the permission changes (or the feature flags), with a proprietary mecanism, the React application will re-render, but not go through a full browser refresh. When this happens, if a user is on a page that he doesn't have access to anymore, we will expect this user to be shown some type of "forbidden" error boundary. We expect that the page will figure out that the user cannot view it anymore by receiving a 403 http status code the next time the page data are fetched from the page dedicated endpoint, this is how we used to deal with this type of stuff before we switched our data fetching strategy to Tanstack Query.

Now, of course we could handle this by throwing the error returned by useSuspenseQuery, but since it affects every page of the application, that's not super convenient.

We could wrap the Tanstack Query hooks and customize the behavior, but we would prefer avoiding doing this.

Is there another option we could consider?

Thank you,

Patrick

[TkDodo]

Interesting case, I don't think there is a good way to do this apart from having a query of the feature flag at the top of the page that re-throws the error.

you can try to set the state of the query from inside the queryFn to "delete" the data, but I'm not sure if that works / is a good idea:

const useFeatureFlag = (name) => {
  const queryClient = useQueryClient()

  return useQuery({
    queryKey: ['feature', name],
    queryFn: async ({ queryKey }) => {
      try {
        const feature = await fetchFeature(name)
     } catch (e) {
        const currentQuery = queryClient.getQueryCache().find({ queryKey })
        // feature flag goes from "on" to "off"
        if (currentQuery?.state.data) {
          currentQuery.setState({
            status: 'pending',
            data: undefined
          })
        }
        throw e
     }

      return feature
    }
  })
}

I think this make it so that the query will be in a "hard error state" afterwards. let me know if that works 😅

but also, while writing this I realised that having a query go to "error" state because a feature flag is turned off is not the right approach. The feature flag query probably returns a value (true or false). false doesn't mean error, it just means you don't have that feature. If you go with errors, you can't distinguish your feature flag request failing from the feature just being turned off. What if you want to display a different screen, like a "you can't see this feature, please buy it here" kind of screen. It's not a case for an error boundary. It just means somewhere, you want a check for "is the feature on?" high up in the tree and if no, display a different UI. so it's more of a UI concern for me rather than an errored query. hope that makes sense.

[patricklafrance]

Thanks for the reply.

I might have created confusion by including feature flags into the mix, my bad. Maybe that would be easier to focus strictly on a permission change use case?

Let's say that a user has the correct permission set to view the page X of a product. The user navigate to the page X of the product and the page renders with data from a dedicated endpoint Y.

Then, an admin of the product updates the permissions of the user so he cannot view anymore the page X of the product.

The user is already on the page X, so there's already a Tanstack Query refreshing the data from the endpoint Y at a given interval. Now the endpoint keeps returning a 403 because the user doesn't have the correct permission set anymore. But instead of throwing an error, the query always return the stale data.

How can the application knows that the user doesn't have the right permission anymore to view the page X and should either display a message explaining the lack of permissionso or redirect the user to another page? Before Tanstack Query, we used to implement such behavior by having our fetch client throwing an error and then a React error boundary takes care of displaying an error message.

Since the user already saw the page X, as long as the user stay on page X, I guess that could be acceptable that he still sees the page and the stale data, but AFAIK, if the user navigates away from page X and comes back later, he will still see the staled data, which is starting to be, IMO, a weird user experience for this use case.

A solution could be to duplicate the permissions in the frontend, but duplicating the permissions logic is not super convenient for maintenance.

If the described use case would be for a single page / query, using the error prop to throw an exception would be acceptable, but at scale, it's very error prone (no pun intended 😆).

My first thought has been to look for a throwOnRefetchError prop or throwOnRemountError prop on either useQuery or useSuspenseQuery hooks, but from what I understand this is not a behavior that is currently pushed by Tanstack Query.

[TkDodo]

The user is already on the page X, so there's already a Tanstack Query refreshing the data from the endpoint Y at a given interval. Now the endpoint keeps returning a 403 because the user doesn't have the correct permission set anymore. But instead of throwing an error, the query always return the stale data.

okay got it, but why isn't there a query further up the tree that would change what is rendered:

const permissionsQuery = usePermissionsQuery()

return permissionsQuery.data?.canSeeProduct ? <ProductPage /> : <UpsellPage />

even if the user is on the product page, and the product query returns 403, as soon as the permissions query refetches, the product page should go away.

other ideas are setting up a global onError handler on the query cache that redirects the user somewhere if they get 403. Or you just rethrow the error manually.

My first thought has been to look for a throwOnRefetchError prop or throwOnRemountError prop on either useQuery or useSuspenseQuery hooks, but from what I understand this is not a behavior that is currently pushed by Tanstack Query.

I'm not currently considering to widen the API surface for this because it looks like an edge case that has lots of good solutions to fix in user-land.

[patricklafrance]

okay got it, but why isn't there a query further up the tree

Good question! That's related to the nature of our application. We are developping a micro-frontends application with Module Federation. We architected our solution to maximise the "remotes" autonomy, meaning that the "host" application doesn't know much about what the remotes includes in the application. Remotes can add routes or menu items at bootstrapping with a dedicated API.

A downside of this architecture is that you can't really add stuff like:

const permissionsQuery = usePermissionsQuery()

return permissionsQuery.data?.canSeeProduct ? <ProductPage /> : <UpsellPage />

Since we are relying on the server as our souce of thruth, I thought we would be fine.

other ideas are setting up a global onError handler on the query cache that redirects the user somewhere if they get 403. Or you just rethrow the error manually.

I haven't thought about this one, I forgot that the onError handler is still available on the query cache, i'll give it a try 🙏🏻

Thank you,

Patrick

[patricklafrance]

I tried adding an onError handler to the query cache client, but it doesn't seems to work as I would expect:

const queryCache = new QueryCache({
    onError: (error: Error) => {
        if (isApiError(error) && error.status === 403) {
            throw error;
        }
    }
});

const queryClient = new QueryClient({ queryCache });

export function QueryProvider({ children }: PropsWithChildren) {
    return (
        <QueryClientProvider client={queryClient}>
            {children}
        </QueryClientProvider>
    );
}

When using useSupenseQuery, on the initial load, if a 403 status code is returned, the page doesn't even render, I am stuck with the Suspense boundary fallback element.

If the page as already rendered sucessfully (meaning that the user is currently viewing the page), if a subsequent fetch returns a 403 status code, the stale data are still shown instead of throwing the error.

I am probably doing something wrong?

[TkDodo]

you can't re-throw errors in onError. This is an "error handler", not an "error thrower" 😅 . It will just put the query in error state (which it already is in), but it will not throw to an error boundary. only components can do that.

my idea was to redirect in the onError handler so that you get away from your page that the user is not allowed to see.

[patricklafrance]

Ahhhh, sorry about that haha.

Got it, thank you!