networkStatus gets stuck on "2" (setVariables)

[SachaG]

Something I've noticed recently: when passing new options to my query container, it can get stuck on networkStatus = 2 even once the request succeeds. Here's a short screencast to demonstrate the issue:

https://cl.ly/kEWd

Note that this only seems to happen the first time these new options are passed. If I go back and forth between both pages, it'll work the second time. This is with apollo-client 1.1.2 and react-apollo 1.1.1.

Other (maybe related) networkStatus issues:

apollographql/apollo-client#1186
#170

[grossberg]

i have the same issue

[josiang]

i also have the exact same issue

[helfer]

Thanks @SachaG! Would anyone be able to provide a reproduction using react-apollo-error-template? 🙂

[josechavezm]

Is there a workaround? like using another version?

[alikhani]

I'm having the same issue.. Any progress?

[helfer]

@hiei189 @alikhani I think this issue is similar to another one we're trying to debug (where the loading state doesn't change back), but we could still use a reproduction for this, in case it's not the same.

[andrewgreenh]

Hello everybody, I encountered this problem as well and I was able to reproduce this in this repo: https://github.com/andreasgruenh/react-apollo-error-template

Take a look at the PersonDisplay component. It receives an ID as prop and should render the corresponding person. To prevent some old state in the PersonDisplay component, I want it to completly unmount and remount it (by giving it a key prop). When I give this prop from the App component, everything works, when I hand this prop from mapProps HOC, it stops working. It also does not happen with react-apollo 1.0.0

[alikhani]

I can try to reproduce it later when I have time. I can confirm that the issue manifests itself in [email protected]. So 1.0.0 works fine.

[helfer]

@alikhani what's the latest version of apollo-client (not react-apollo) that it works with and the first version where it breaks?

[alikhani]

@helfer I'm importing apollo-client from react-apollo. Not sure how the dependencies work..
[email protected] that works for me has the dependency: apollo-client "^1.0.0-rc.9". In my node_modules the version I find is apollo-client 1.2.2.

In react-apollo 1.0.0 where it breaks it says that it should use "^1.0.2" #L132

So I think I'm using the latest apollo-client release(1.2.2), due to the "^", on both versions.

[helfer]

@alikhani can you try this again after you set the version in your package.json explicitly react-apollo@^1.2.0, then rm -rf node_modules && npm install. Then npm list | grep apollo should tell you which versions you have.

[jole78]

I can also confirm that this is an issue. However, I got it working by downgrading react-apollo to 1.0.0

This is my setup (working):
[email protected]
[email protected]

Also using:
fetchPolicy: "network-only"

Upgrading react-apollo makes the network status stuck in "2", thus loading is always true and my UI is showing the "loading spinner".

[helfer]

@jole78 interesting! Can you tell us at exactly which version of react-apollo things start breaking? That will help us narrow down which change caused this.

[josechavezm]

I get this when running yarn list | grep apollo

├─ [email protected]
├─ [email protected]
│ ├─ apollo-client@^1.0.2

and it is working ok.

but I couldn't make it work with react-apollo 1.2

[jole78]

@helfer sorry for the late response. Anything higher than 1.0.0

[robertvansteen]

I can confirm I have this issue too. Had to downgrade to 1.0.* for it to work properly.

[c10b10]

I can confirm the issue as well. Downgrading to [email protected] fixed it.

[kolpav]

This problem is driving me crazy. If there is any way how I can provide some information to help you narrow down the problem let me know.

[bogdansoare]

Also have this problem

[igorlamos]

Same for me ... thanks for info about downgrade, which also solved the problem for me.

The following works fine:

├─ [email protected]
├─ [email protected]
│  ├─ apollo-client@^1.0.0-rc.9

The following does not work:

├─ [email protected]
├─ [email protected]
│  ├─ apollo-client@^1.0.2

[helfer]

It seems like this was caused by #531, and indirectly by adding recycled queries in the first place. I'll take another look to see if I can figure out what's causing it based on the reproduction by @andreasgruenh.

[jbaxleyiii]

@helfer yeah recycled queries felt like it added in a lot of complexity / bugs. I wonder it it's worth taking a look at a different approach?

[helfer]

@jbaxleyiii At this point I think recycled queries are there just for backwards compatibility to support updating queries that aren't currently being used. For folks that are using only update or who are never updating the cache, we could turn them off completely. We can make them opt-out for now, and for the next major version of react-apollo we'll make them opt-in. Do you see any issues with that approach?

[jbaxleyiii]

@helfer I like it!

[andrewgreenh]

Could you elaborate on the meaning of "queries that aren't beeing used"? Let's say I have 2 routes, on one route is a list of all cars, on the other Route there is a button to add a car. Can I still update the cars list while beeing on the add car site (list site is not mounted)?

[SachaG]

Can I still update the cars list while being on the add car site (list site is not mounted)?

@helfer will correct me if I'm wrong, but I think the answer is that without recycled queries, you can do this if you use update, but you can't if you're using the (probably soon deprecated if they aren't already) updateQueries or a reducer.

[helfer]

@andreasgruenh It's basically what @SachaG said. You can't reference the query by name, but you can update the cache using the update function. This is because if the query isn't active any more, it will no longer be tracked and thus can't be updated by name.

[jbaxleyiii]

good news everyone! This will be fixed in 1.4.0 which should release tomorrow!

[jbaxleyiii]

This is now fixed via 1.4.0! You will need to update apollo-client to the same version!

[igorlamos]

GREAT! Works for me ... Updated to:

├─ [email protected]
│  ├─ apollo-client@^1.4.0

and problem solved! Awesome work 👍

[slackday]

I can confirm this works with react-apollo: 1.4.2 and apollo-client: 1.4.0.

I ran into this issue when refactoring my code from using multiple graphql queries to a single. Thought I had some error in my components and without being able to resolve it myself I started looking for similar issues and found this.

network status got set to 2 and being stuck there when only changing the query variables calculated from props. I see it being related to query re-use which makes sense.

Great job everyone in resolving this! And thanks :)

[amannn]

This is still the case for me with:

"react-apollo": "^2.5.3",
"apollo-client": "2.5.1",

Can we reopen this @jbaxleyiii?

Using fetchPolicy: "no-cache" was a workaround for me.

[tonywei92]

I'm still having this problem, the refetch query's networkStatus stays 2 forever, but it's only happen if after a mutation is occured