QueryErrorResetBoundary does not reset the state of the query

[Trancever]

Describe the bug

QueryErrorResetBoundary does not seem to reset the query in suspense mode.

To Reproduce
Steps to reproduce the behavior:

https://codesandbox.io/s/sweet-greider-edmen

It's a slightly changed suspense example. I added a button that toggles a shouldThrow state. shouldThrow is passed to the Project component and based on its value, fetch function throws or fetches the data from API.

Steps to reproduce:

1. Click "show projects".
2. Open one of the projects
3. Go back to the list of projects
4. Change shouldThrow to true
5. Open a project again -> this should throw the error
6. Change the shouldThrow to false
7. Click "try again" -> this will throw again, but shouldn't

Expected behavior
After calling reset all queries nested in QueryErrorResetBoundary should be reset to some default state and they should try to fetch the data again.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: MacOS
• Browser: Chrome
• Version: latest

Smartphone (please complete the following information):

• Device: iPhone X
• OS: iOS 14
• Browser: React-Native
• Version: latest Expo

Additional context
This happens in both react and react-native.

[arnaudbzn]

Issue reproduced with react-query v3.12.0 and react-error-boundary v3.1.0.

In the codesandbox example, a workaround is to manually remove the queries just before calling resetErrorBoundary():

<Button
   onClick={async () => {
      await queryClient.removeQueries("project", {
        active: false
       });
       resetErrorBoundary();
    }}
>
    Try again
 </Button>

This issue is weird because react-query seems to have a unit test to cover this use case.

[Trancever]

@tannerlinsley I was able to narrow the issue down to the keepPreviousData property. When it is true and the error happens, reset function from QueryErrorResetBoundary doesn't reset the error. Is this behaviour expected?

Anyway, we don't use keepPreviousData anymore so it's no longer an issue for us.

[escaton]

I also faced this issue but in my case the problem caused by initialData in query options.
Check App.js:71 https://codesandbox.io/s/gracious-snowflake-4zps1?file=/src/App.js

[Trancever]

Just did another round of testing yesterday and found out that even without keepPreviousData resetting doesn't work in 100% of cases. It works for me when the error happens in the initial fetch, but if I call refetch programmatically and the function throws, then reset no longer works as expected.

As a workaround, I reset queries manually with queryClient.resetQueries. It's not ideal tho, cause I need to know what queries are rendered in the component tree.

[escaton]

@TkDodo it also doesn't work with { suspense: false, errorBoundary: true }

[TkDodo]

interesting. so what's the minimal example to reproduce please, then I can try to add a test for it.

what I am seeing is that we create the QueryErrorResetboundaryValue with useMemo, which is not guaranteed to be only called once:

https://github.com/tannerlinsley/react-query/blob/ac342e237ae9fab6759f2d7be616662da6c16225/src/react/QueryErrorResetBoundary.tsx#L44

maybe concurrent mode discards that at some point, and we should useState here instead?

const [value] = React.useState(() => createValue())

but if you have an example without experimental suspense / concurrent mode, that would be great.

[escaton]

The minimal example is here https://codesandbox.io/s/gracious-snowflake-4zps1?file=/src/App.js
And from what I've managed to dig up, looks like the problem is somewhere around new Observer
https://github.com/tannerlinsley/react-query/blob/master/src/react/useBaseQuery.ts#L63
which returns isError: true for previously failed query even if reset boundary is reseted:
https://github.com/tannerlinsley/react-query/blob/master/src/react/useBaseQuery.ts#L112

[TkDodo]

thanks. your example works in v3.3.3, but breaks in v3.3.4

here is the diff, and I highlighted the line where the check for !errorResetBoundary.isReset() was removed.

v3.3.3...v3.3.4#diff-1486bf9371a46f2a5a849e437c96eb09808ae49a4eebbd32f312b18bc87caf99L80

@boschni can you shed some light here maybe? simply adding that check back seems to work with my limited testing 🤔

[Shaddix]

#2222 is probably one of repro-cases for this issue

[Shaddix]

btw, PR #2147 together with returning back the check for !errorResetBoundary.isReset() (mentioned by @TkDodo) fixes my mentioned issue as well.

[talksik]

FYI: I see this issue with useSuspenseQuery. The suspense query that leads to the error boundary is not reset correctly. It makes it so that the second time the user goes to the page with the same useSuspenseQuery, it will hit the error boundary again.