errorPolicy ('ignore' and 'all') doesn't work in case of network error

[dbelchev]

Intended outcome:
Solution 1: In case of a network error errorPolicy set to 'ignore' or 'all' should prevent unhandled Apollo exception.
Solution 2: If this is expected behaviour, please update the official documentation.

Actual outcome:
Network errors cause unhandled Apollo exception even if errorPolicy is set to 'ignore' || 'all' on query options and ApolloClient defaultOptions level.

How to reproduce the issue:
Create a network request which returns response code 401.

Use errorPolicy set to 'ignore' || 'all' in query options, or in ApolloClient defaultOptions.

Version

• apollo-client@2.2.0 and apollo-client@2.2.5

[mbrowne]

Note that this is also an issue for response code 400. If you throw an error from your resolver in the server, then that error will be returned when errorPolicy is set to 'all', but if there's an error in your query (e.g. invalid field) then it just returns this generic message:

Network error: Response not successful: Received status code 400

[csantos1113]

apollo-client/packages/apollo-client/src/core/QueryManager.ts

Lines 503 to 508 in 905001e

	if (
	((!errorPolicy || errorPolicy === 'none') &&
	queryStoreValue.graphQLErrors &&
	queryStoreValue.graphQLErrors.length > 0) ||
	queryStoreValue.networkError
	) {

Shouldn't be:

    if (
      (!errorPolicy || errorPolicy === 'none') &&
      (
        (queryStoreValue.graphQLErrors && queryStoreValue.graphQLErrors.length > 0) ||
        queryStoreValue.networkError
      )
    ) {
      // code
    }

?
cc: @benjamn / @hwillson

[nhuesmann]

Note that this is also an issue for response code 400. If you throw an error from your resolver in the server, then that error will be returned when errorPolicy is set to 'all', but if there's an error in your query (e.g. invalid field) then it just returns this generic message:

Network error: Response not successful: Received status code 400

I'm having the exact same issue. Sending a query that doesn't follow the schema results in a network error as described here. It also returns a GraphQLError, but I can't access that because the network error is throwing regardless of my errorPolicy setting. Is this intended behavior? Is it expected that a query/mutation that doesn't adhere to schema would cause the client to throw, no matter what?

[brandondoran]

I'm running into this too. Using errorProlicy: 'all', if a request results in a 400 or 500, the error on the client goes unhandled. I have apollo-link-error middleware where I'm logging and can see it's a networkError. When this happens during sever render, you're pretty much screwed. It may not even be a critical request. Why should it have to fail the whole page load?

The errorPolicy and Network Errors docs make it sound like these network errors shouldn't go unhandled like this with the all policy and/or when using error middleware. But perhaps the docs are misleading or there's a bug? What is the recommended approach to handling network errors?

[joepuzzo]

So this issue has been open for a really long time and ( unless I and others in this thread have a complete misunderstanding of how apollo should handle these errors ) It seems very high priority.

Again to summarize the big issue here:

ITS CURRENTLY IMPOSSIBLE TO GET ACCESS TO RELEVANT ERROR INFORMATION WHEN A NON 200 STATUS CODE IS RECEIVED.

I have been using apollo for nearly a year now and my work around has been to never set a field to non nullable ( ! ). This seems to be a hack.

[mbrowne]

@joepuzzo I would not sacrifice the correctness of your schema because of this. A better workaround is to go to the network tab in dev tools where you can see the full error message. But yes, this is a significant issue in Apollo client and should be fixed.

[joepuzzo]

LOL yes i as a human can go to the network tab and see my errors. I need my code to do it though LMFAO 😆 . Agreed very big issue

[joepuzzo]

@hwillson Maybe you can at least give some clarity into this issue as its been going on for so long. Are we just misunderstanding the design? Or is this a bug?

[brandondoran]

Going to the network tab is a good way to debug it in development but this does not cover:

1. Server side render
2. Reporting these errors where it counts, for real users in production.

Network errors are going to happen. It may be a transient error for 1 request. That shouldn't brick the app when it happens on a server render.

I agree with you @joepuzzo this is either a huge issue / design flaw or we are not using it in the intended way. The issue is over 1 year old with not response from the core team. @benjamn @hwillson

[hwillson]

Would anyone here be able to provide a small runnable reproduction that clearly shows this issue? This sounds more like an Apollo Link (https://github.com/apollographql/apollo-link) issue, but a repro would help confirm.

[brandondoran]

Thanks for the quick response @hwillson. I will put together a repo to reproduce it. It very well may be apollo-link.

[joepuzzo]

@brandondoran I have created these two sandboxes to help show this issue #4644 and i think also pertains to this issue as well.

https://codesandbox.io/s/w7qy5m1pw7 << UI using apollo client
https://codesandbox.io/s/5wlv3jlywn << Server using apollo server

A couple things to note:

1. The following parameters seem to have NO affect on the policies.. you MUST put the param on the <Query> component.

defaultOptions: {
    watchQuery: {
      errorPolicy: "all"
    },
    query: {
      errorPolicy: "all"
    },
    mutate: {
      errorPolicy: "all"
    }
  }

2. Putting errorPolicy="all" on the query makes it so the cacheing takes place ( the request is made every time other wise (i find this to be incorrect).

[joepuzzo]

To reproduce: Go to the home page and refresh the browser. Then navigate to the dog page. You will see an error. Then navigate back to home and then back again to dog the error was not cached and there was obviously no re attempt to get the data again <<< which would also be a nice feature.

[jhiode]

It looks like it will be fixed in 1.6.0:

apollo-client/packages/apollo-client/src/core/QueryManager.ts

Lines 573 to 575 in d33eb3e

	// If we have either a GraphQL error or a network error, we create
	// an error and tell the observer about it.
	if (errorPolicy === 'none' && hasGraphQLErrors || queryStoreValue.networkError) {

Edit:
Ok that is not true, we still need the parentheses there:

if (errorPolicy === 'none' && (hasGraphQLErrors || queryStoreValue.networkError))

[jbaxleyiii]

Thanks for reporting this. There hasn't been any activity here in quite some time, so we'll close this issue for now. If this is still a problem (using a modern version of Apollo Client), please let us know. Thanks!

[joepuzzo]

This is still an issue ...

[mbrowne]

@jbaxleyiii Can you reopen this please?

[pdoyleTQ]

I don't want to have to return a 200 in the case when the request errors out in a way that the user needs to know about, but I don't see any other path forward if this remains as is.... it just eats any 400 responses and doesn't allow for the configuration parameter that is supposed to override this option to do its job so I can let the user know what the error is somewhere other than the dev console, so they can go and fix it.

What is the alternative?

Edit: the alternative ended up being switching to Urql.

[ppinel]

@jbaxleyiii I am experiencing the issue. I can't get GraphQL error because of the network error when response's status code is different than 200.
Is this from apollo client or a middleware? Can you give us at least more information?
Also @hwillson ask for a exemple to test the issue but never get back to us.

[luisbritescarvalho]

I found this issue one year ago and I'm still struggling with that. Anyone could find a workaround?

Like it was already said, if you have a network error in meaningless request during SSR everything breaks :/

[casiodk]

I would also like to have this reopened

[mbrowne]

You're probably better off opening a new issue. Just speaking generally (not even specific to Apollo), closed issues rarely get attention from maintainers.