RTK Query: don't refetch on subscribe after error

[nrmilstein]

I have a pretty basic endpoint for getting the current logged-in user that looks like this:

getUser: builder.query<User, void>({
  query: () => 'users/me',
  providesTags: ['User'],
  keepUnusedDataFor: 9999999, // Keep the user in the cache until sign out
}),

If the user is unauthenticated, this will return 403. When a component subscribes to this query, if it is in this 403 state, then it will refetch on mount. If it responds with 200 and some data, then RTK Query is satisfied and will not refetch the data on mount (I have refetchOnMountOrArgChange: false).

Is there any way to not refetch this on mount if there's been an error? I only want to refetch it when the 'User' tag is invalidated. I know I could probably define a custom queryFn to not error on 403, and instead return success and some placeholder user data. But I wanted to ask if I was doing this correctly.

Thanks!

[nrmilstein]

I worked a bit more and think I understand this better now. RTK Query isn't really designed to consider an error response from the server as indicating "no data"; rather it interprets it as "could not access the resource" and attempts to load it again on a new subscription.

I've decided to handle auth logic (fetching the authenticated user, sign in, etc.) just using regular Redux actions, and save RTK Query for all the stuff after.

Thanks for making this library, it's been enjoyable to use :)

[phryneas]

Sorry for the late response - I actually had looked at the issues and not found this one again 😅

Honestly, I think I just missed this scenario conceptually when writing that part of the lib. Now the question is what the best behaviour would be. 🤔
I think the current behaviour makes sense, but we will probably need a way to opt out of those refresh retries - probably a refetchOnError option on hook level, endpoint level (and maybe even api level) that defaults to true but can be changed.

[nrmilstein]

Thanks for your reply. That was roughly what I was thinking as well. The current behavior does seem to make sense to me as well, but I can see a case where an error should be handled differently. The other problem is there are certain errors I probably would want to refetch on, and certain I wouldn't – 502 bad gateway: try again later; 403 forbidden, don't retry. Sort of like how providesTags can provide different tags on success or error, except this would be different data/behavior.

Another problem I was having was purging data from the cache. I was manually calling invalidateTags on logout to try and invalidate the 'User' tag and lots of associated user-data. However, this would not immediately clear the data from the cache (important for not leaking user data between logins), but would cause those endpoints to refetch a 403 error, and the data wouldn't be cleared. Calling resetApiState works, but is not targeted towards specific tags, and I ran into the issue where hooks tracking state in local component state would not update.

I can see all of this being done with options, like refetchOnError andpurgesTags: ['User', ...], which would immediately purge the cache for those tags. But of course I have no idea how common this use case is, and for all my other needs the current behavior seems ideal. 😃 Thanks!

[phryneas]

Tbh, instead of purgesTags I would just go with a lifecycle callback like onQueryStarted and call either invalidateTags or resetApiState. But as you noticed, that will refetch queries for component that are still mounted - so you maybe should wait util those are unmounted.

[nrmilstein]

Thanks, I'll definitely use that way if I try again.

[a-b-r-o-w-n]

@phryneas Do you have a suggestion on how to handle things like 404s? I am experiencing an infinite refetch on an error that the only way I've found to address is by returning { data: null } or something similar.

Let's say I have a component that fetches a post and an author, if the post returns a 404 I see it keep attempting to refetch. Maybe I am doing something wrong, but I've exhausted my investigation so far and could use some help.

function Post({ postId }) {
  const { data: post, isLoading: postIsLoading, error: postError } = useFetchPost({ postId });
  const { data: author, isLoading: authorIsLoading } = useFetchAuthorByPost({ postId });

  if (postIsLoading || authorIsLoading) {
    return <div>Loading...</div>;
  }

  if (postError) {
    return <div>Failed to load post</div>;
  }

  return <h1>{post.title} - {author.name}</h1>
}

[a-b-r-o-w-n]

Also note that we are using a custom base query but in this case it is returning a serializable error in the form of:

{ status: number; message: string }

[phryneas]

I'd have to see that - that shouldn't be happening.

[smacpherson64]

Just possibly hit a similar issue to this. In our case, the parent component conditionally rendered descendants based on the isLoading state.

The isLoading state seems to be connected for all hooks subscribed to the same query with the same args. This caused the parent to unmount the children unexpectedly for us.

The infinite loop looks like this:

1. Parent loads data, descendant not mounted. (isLoading: true)
2. Parent result is error, descendants mounted. (isLoading: false)
3. Descendant triggers refetch for new data. (isLoading: true)
4. Parent's isLoading resets to true (unmounting descendants... and looping back to 1.)

We were expecting isLoading (for the Parent) to stay the same since the request was already sent previously for the same args on the same query.

The refetchOnError option talked about above would be really nice for our case, as the descendant would not trigger a refetch for new data.

Hopefully this is helpful.

EDIT: removed gist example to prefer recreation below.

[markerikson]

@smacpherson64 that sounds unexpected. isLoading is only true for the first time a given query runs - it doesn't get set to true on later refetches. isFetching will turn true for all fetches of that query.

[smacpherson64]

@markerikson thank you for the response and agreed it was unexpected! Here is a recreation of the issue:
https://github.com/smacpherson64/rtk-infinite-loop-issue

If you have time, I would very much appreciate if you would verify if you experience the same issue. If you would like it in a different format please let me know!

Attempted a PR to fix the issue: #4364

EDIT: adds attempted PR link