Skip to content
This repository has been archived by the owner on Apr 13, 2023. It is now read-only.

After a graphQL error (ex: status code 404) the component won't update with loading until a successfull request #3491

Closed
Mrtblg opened this issue Sep 12, 2019 · 6 comments

Comments

@Mrtblg
Copy link

Mrtblg commented Sep 12, 2019

Say you have component wrapped by the HOC graphql from 'react-apollo';

Say you make a request with params (variables).

And imagine the following scenario :

First request with some params/variables
Receive a 404
Second request (params/variables changed)
Receive a 200

I would expect :

Loading state
Error state
Loading state
Sucess state with data

Instead i have :

Loading state
Error state
Error state
Sucess state with data

I tryed to make my way around this by catching the error 404 in the onError from 'apollo-link-error' and doing response.errors = null;

Catching the error kind of improve my situation, my previous scenario goes like this :

Loading state
Error state (but this time the graphQLErrors is undefined and the networkError bares the error saying that appollo couldn't write in the cache, probably because it tries to insert structured required data with undefined).
Loading state <-- here the problem is solved
Sucess state with data

But it's a pain that I still have an error, not detailed once read in data in the component althought i catched it...

That makes me belive :

graphql does not react well on the life-cycle after an error
catching errors in onError with response.errors = null; does not work completely since it creates a cache error in the networkError (which by the way makes little sense to me).

@dylanwulf
Copy link
Contributor

What version of react-apollo and apollo-client are you using? Do you have the notifyOnNetworkStatusChange option set to true?

@Mrtblg
Copy link
Author

Mrtblg commented Sep 12, 2019

I'm using 3.1.0 and I tryed playing around with notifyOnNetworkStatusChange, true or false it has no impact on my problem.

setting fetchPolicy "no-cache" or "network-only" is pretty much the only thing that solves the problem but i really don't want to do it.

@dylanwulf
Copy link
Contributor

Could you please create a runnable reproduction that shows the issue you're experiencing? Maybe using something like codesandbox.io?

@Mrtblg
Copy link
Author

Mrtblg commented Sep 12, 2019

Is there a simple solution to mock the server response with an error status code ?
Otherwise it's quite a big set-up

@Mrtblg
Copy link
Author

Mrtblg commented Sep 12, 2019

It's quite some work to produce the sandbox out of the blue i imagine you have a set of your own I could fork and modify ?

@Mrtblg
Copy link
Author

Mrtblg commented Sep 13, 2019

After some struggling and tests, it happens that I was using apollo-client ^2.4.7

after upgrading all my apollo dependencies to the latest :

    "apollo-cache-inmemory": "^1.6.3",
    "apollo-client": "^2.6.4",
    "apollo-link-context": "^1.0.19",
    "apollo-link-error": "^1.1.12",
    "apollo-link-http": "^1.5.16",
    "apollo-link-ws": "^1.0.19",
    "apollo-utilities": "^1.3.2",

My problem got fixed and transformed into this very well identified one :
#3425

So I close the issue

@Mrtblg Mrtblg closed this as completed Sep 13, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants