Skip to content

Conversation

@jbee37142
Copy link
Contributor

Related issue: #2187

Description

Change shouldFetchOptionally condition to not change the status of result to loading when state.status is error.

  1. result.isLoading is true in this line when result.error != null
  2. So the error did not propagate to the error boundary. (next condition)
  3. Check the createResult function and shouldFetchOptionally function

Fixes #2187

Special thanks to @flybayer

@vercel
Copy link

vercel bot commented Aug 10, 2021

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/tannerlinsley/react-query/9aHMnSCooAbKNSo9bLf5zZ1EP9zM
✅ Preview: https://react-query-git-fork-jaeyeophan-fix-should-7780ae-tannerlinsley.vercel.app

@codesandbox-ci
Copy link

codesandbox-ci bot commented Aug 10, 2021

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 9b0e0e4:

Sandbox Source
tannerlinsley/react-query: basic Configuration
tannerlinsley/react-query: basic-typescript Configuration

Change this condition to not change the status of result to 'loading'
when state.status is 'error'

Fixes TanStack#2187
Change to refer to the previous query value.
Check prevQuery.state.status only when prevOptions.enabled is false
@TkDodo TkDodo merged commit 69f1eaf into TanStack:master Aug 11, 2021
@tannerlinsley
Copy link
Member

🎉 This PR is included in version 3.19.5 🎉

The release is available on:

Your semantic-release bot 📦🚀

@jbee37142 jbee37142 deleted the fix/shouldFetchOptionally-condition branch August 12, 2021 16:11
TkDodo added a commit to TkDodo/react-query that referenced this pull request Sep 18, 2021
the change in shouldFetchOptionally was introduced in TanStack#2556 to avoid an infinite loop wen using suspense (see TanStack#2187), but it broke the case where we're switching keys between two erroneous queries - they now didn't refetch even though they should

this fix scopes the error check to only usages where suspense is turned on, so that we get the same behaviour as in v3.19.4 for non-suspense users, while still having the fix for suspense users
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

suspense useQuery infinite loop when query goes from success to false and query key changes

3 participants