Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

useSuspenseQuery returns an error instead of throwing an exception #11800

Open
tarasmatsyk opened this issue Apr 22, 2024 · 6 comments
Open

useSuspenseQuery returns an error instead of throwing an exception #11800

tarasmatsyk opened this issue Apr 22, 2024 · 6 comments

Comments

@tarasmatsyk
Copy link

tarasmatsyk commented Apr 22, 2024

Issue Description

I am using a suspense query and an error boundary to catch all unhandled errors. An example of usage:

  // this component is wrapped in ErrorHandler and React.Suspense, error and networkStatus are just for debugging
  const {data, error, networkStatus} = useSuspenseQuery<MyType>(Query, {variables: myVariables});
  // data = null, error = "posted a few lines below", networkStatus: 8

everything works fine in 3.8.x, after update to 3.9.0+ suspense no longer throws an error and behaves more like useQuery hook without a loading property

an example of error

ApolloError: "error message coming from API"
    at new ApolloError2 (index.ts:101:10)
    at toApolloError (useSuspenseQuery.ts:322:7)
    at useSuspenseQuery.ts:275:14
    at mountMemo (react-dom.development.js:17225:19)
    at Object.useMemo (react-dom.development.js:17670:16)
    at Object.useMemo (react.development.js:1650:21)
    at useSuspenseQuery (useSuspenseQuery.ts:269:16)
    at CustomComponent
    at renderWithHooks (react-dom.development.js:16305:18)
    at mountIndeterminateComponent (react-dom.development.js:20074:13)

perhaps react-dom is involved somehow, I have a limited understanding of what happens here and cannot reproduce the issue if I pass my GQL response into unit tests apollo-client has (or I am bad at it)

server response example

{
   "data": null,
   "errors": [
       {
           "message": "error message coming from API",
           "locations": [
               {
                   "line": 2,
                   "column": 3
               }
           ], // no idea where this comes from
           "path": [
               "items"
           ],
           "extensions": {
               "code": 4,
               "exception": null
           }
       }
   ]
}

Unfortunately, I don't have more details at the moment. I am leaving this issue in case someone else faces similar behavior and I am able to get a reproducible sample

Link to Reproduction

N/A

Reproduction Steps

also discussed here:
#11664

@apollo/client version

3.9.0

@jerelmiller
Copy link
Member

Thanks so much 🙂

@jerelmiller
Copy link
Member

Hey @tarasmatsyk 👋

I wanted to provide a gentle nudge and see if you are able to provide a reproduction of the issue. We've got this hook tested pretty thoroughly in regards to errors, so either we missed an edge case or something else is at play here. A CodeSandbox or Replay of the issue would be great. If you'd like to go the CodeSandbox route, we have template use can use as a starting point.

Thanks!

@jerelmiller jerelmiller added the 🏓 awaiting-contributor-response requires input from a contributor label May 13, 2024
@tarasmatsyk
Copy link
Author

@jerelmiller thanks for a follow-up, but I still don't understand how to catch the difference.

I can confirm the issue is still present at 3.10.4, react 18.3, react-dom 18.3.

Could the apollo client expect network error as my server returns a 200 OK response with an error? I doubt the issue is in the useSuspenseQuery file, it's either caching or some other place. I get an error in the skipResult function, in one case componentDidCatch is called on the error boundary and in another (3.10.+) - it's not.

@jerelmiller
Copy link
Member

@tarasmatsyk I'm really sorry to sound like a broken record, but its extremely difficult for me to understand what might be happening without a reproduction. I don't doubt this is happening to you, but I don't even know where to begin since I don't know what condition causes it to return an error instead of throw. If you're able to provide me with a reproduction, I'd be happy to dig in further.

Could the apollo client expect network error as my server returns a 200 OK response with an error?

This shouldn't be it since a 200 response is pretty standard GraphQL behavior with errors. The error format you provided in your server response also looks fine.

I get an error in the skipResult function

Could you expand on this? We don't have a skipResult function that I'm aware of so I'm not entirely sure what you're referring to 😅

Let me note too that I don't expect a reproduction in the form of writing a test case in our own useSuspenseQuery tests. You're certainly welcome to do that if you're able to get this reproduced, but a small React app that demonstrates the issue also works great. Our CodeSandbox template is a good place to start if you need something already spun up. Alternatively, sending me a Replay of your dev environment would also help me dig in further. If you have sensitive data here that you'd rather not share, no worries, the CodeSandbox would work just fine.

@tarasmatsyk
Copy link
Author

@jerelmiller I get it, I barely can get any reproduction steps, your suggestions def help.

I was referring to this skipResult, but it might be more misleading than helping, perhaps worth ignoring until I get a reproducible sample

const skipResult = React.useMemo(() => {

Let me try to reproduce the issue on a small app.

@tarasmatsyk
Copy link
Author

tarasmatsyk commented May 20, 2024

@jerelmiller I think I misled you with the original report, I had a hook a few components above with reFetchObservableQueries whenever a user context changes which (in my theory) prevents the error boundary from capturing the error.

I am doing more investigation to see how this mess works together :) (not the apollo one :D )

PS. Once I removed the hook above, it all started working

@github-actions github-actions bot removed the 🏓 awaiting-contributor-response requires input from a contributor label May 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants