Apollo-client: Loading never gets updated to "false"

[tomitrescak]

Hi, this is very indeterministic behaviour. But sometimes the loading flag never get updated to true false. I can see that data are correctly received by client in the console. Any idea how can I debug this to report why is it not getting updated?

[derek-duncan]

I am experiencing this issue as well. The APOLLO_QUERY_RESULT comes through the console, but the loading flag never updates.

[schickling]

In our case the loading flag is not properly updated after calling client.resetStore().

[helfer]

@tomitrescak does the loading flag never get updated to true or never updated to false? Your title says one thing, but in the text you write something else. Would any of you be able to provide a reproduction?

[schickling]

In my case: It gets set to true once I'm calling client.resetStore() but never back to false. (Note: The data in the store before and after the client.resetStore() call is the same in this case).

[tomitrescak]

Sorry for the confusion, yes the situation is the same, I call resetStore and it reloads data but never gets updated to false.

[calebmer]

@schickling, @tomitrescak what versions of Apollo client are you on? I’m trying to reproduce the error, but loading is getting correctly set to false for me. If you are on version 0.7.x could you provide more detail?

[calebmer]

Out of curiosity does an error occur in GraphQL when your query is re-fetched? We’ve seen that cause some issues before.

[tomitrescak]

@calebmer I'm on 0.6.0. After I have upgraded to 0.7.3, it seems it works better. Let me test it further as I had problems on several spots. Can @schickling also report if upgrade helped?

[schickling]

We're running on 0.7.3. Problem still occurs.

@calebmer you can find our use case here. I'm happy to provide more context via Slack.

[calebmer]

@schickling Could you try with https://github.com/apollostack/apollo-client/pull/1202? I’ll see if I can reproduce this in a test.

[calebmer]

(here is the test by the way that models the correct behavior: https://github.com/apollostack/apollo-client/pull/1202/files#diff-3e9523eee379c5b7eca8da84dae6bbe5R3092)

[tomitrescak]

Ok, it is NOT updating for me as well. It's quite indeterministic ;(

[calebmer]

Hmm, ok, we’re going to need more context then. Is perhaps a query running when you call resetStore? I could see how canceling an in-flight query could cause some issues.

@tomitrescak and @schickling definitely try https://github.com/apollostack/apollo-client/pull/1202 so we can see if that fixes it.

[schickling]

@calebmer can you release a temporary version? Afaik yarn still has a bug so I cannot install from a branch.

[calebmer]

We might be able to just do a patch release as all of the tests still pass. cc @helfer

[rhmoller]

I tried to checkout master of this repository and react-apollo and npm link them into my project, but it seems react-apollo is not up to update with the latest changes in apollo-client. Instructions on how to properly try out #1202 would be appreciated.

I tried to manually hack the changes from #1202 directly into the apollo client umd bundle inside node_modules. After this change the loading flag behaved correctly, but "data" was not set unless we set returnPartialData to true in the query options.

[tomitrescak]

Hi, just following up. This is still persistent in 0.10.0 after the brand new batchingnetworkinterface. Can I somehow help? I just don't know where to start and what to watch for.

[schickling]

Can confirm. This is really a severe problem for us using Apollo Client. Is this somewhat on your roadmap for 1.0 @helfer?

[tomitrescak]

@schickling a temp solution for now (unless you are using streaming data) is to check for existence of data in the "data" property, and not the "loading" property. But yes, a systematic solution would be helpful.

[twelvearrays]

@tomitrescak This is what I am doing also.

[helfer]

@tomitrescak @schickling I want to make sure this gets fixed, but it's a bit difficult without any reproduction. Even an indeterministic one would be better than nothing. Can one (or both) of you try creating a reproduction with https://github.com/apollographql/react-apollo-error-template?

[schickling]

I'll try to come up with a minimal example over the weekend. Maybe @tomitrescak can provide one earlier?

[twelvearrays]

In my current project which is built in React Native on iOS. We link to business websites based on the users location. I have noticed that when I go to a business website from the app and Apollo polls for updates while the app in not in the foreground then return to my app is normally when the loading variable is not set to false even though I have all my data. This does not always happen but it is repeatable if I do it a few times.

I will try to get a example project up this weekend also. I am also happy to share my current project if you think that would help.

Thanks!

"apollo-client": "^0.10.0",
"graphql-tag": "^1.3.1",
"react": "15.4.2",
"react-apollo": "^0.13.1",
"react-native": "^0.42.0",
"react-redux": "5.0.3",
"redux": "3.6.0",
"redux-thunk": "2.2.0"

[thifranc]

Hi !

I'm currently working on a project where I need to handle different languages.
When a user swap from French to English, I change the graphql URI and i reset my apollo store in order to update my data :

window.__APOLLO_CLIENT__.networkInterface._uri = window.__APOLLO_URL__;
window.__APOLLO_CLIENT__.resetStore();

When the freshly fetched data is different from the old one, there is no problem, my component re-render with the freshly fetched data.
But, if the freshly fetched data is the same as the old one after the "update" fetch, the props.data.loading is left to true, so my component is re-rendering but cannot load this code :

                    <ul>
                        {!this.props.data.loading && this.renderProducts() }
                    </ul>

what I expect
I expect the props.data.loading to be set to false as the data has been fetched
what I have
data.props.loading is set to true (because the freshly fetched data is the same as the old one I think) and then my component cannot re-Render properly
Reproduce the issue
do a resetStore() that would call a graphql route and which would return the same data, and try to render a component when this.props.data.loading is set to false.

[helfer]

@schickling did you manage to build a minimal reproduction for this?

[calebmer]

It looks like @kouak ran into a similar issue here: https://github.com/apollographql/react-apollo/issues/518

@schickling can you confirm that this is the same issue?

[Peterabsolon]

I'm experiencing the same problem. When I call data.refetch() it sometimes get stuck in loading: true.

[derek-duncan]

What's the status on this? Do we still need a reproduction?

[saudpunjwani101]

It's a bit weird in my case, it was working okay in testing but when I generated a signed apk in react native and run that. For some queries loading never goes false. It's just loading forever, but it works fine in testing environment

[majodev]

Really not sure how to reproduce this, NetworkStatus however works as expected, so you can use a little helper like this as a workaround to properly track the loading state in your components, until this issue is fixed:

import { NetworkStatus } from "apollo-client";

export default function isLoading(ns: NetworkStatus): boolean {
    return (ns === NetworkStatus.ready || ns === NetworkStatus.poll) ? false : true;
}

[saudpunjwani101]

Well I fixed it, it didn't have to anything to do with Apollo client. It was happening because of something other component. It's strange though cuz it worked in debug mode and not in production.

[Florentijn]

+1. We have it in our react application as well.
What we do to get this strange loading behaviour:

• Login to portal.
• Data gets queried and displayed normally.
• Logout user. --> Component that queried data unmounted, and client.resetStore() is called.
• Login new user. --> loading in data prop stays true, and no query result returned

[Florentijn]

Maybe this is helping someone: Downgrading "react-apollo" from 0.13.2 to 0.10.1 seems to fix the loading stays true issue I had for now.

[stevewillard]

Just wanted to echo @Florentijn I'm getting this problem with 1.0.4, but downgrading to 0.10.1 fixes my issue.

[Peterabsolon]

Same here, downgrading to 0.10.1 fixed my issue. :|

[helfer]

@Peterabsolon how about Apollo Client 1.2.2?

[NickDubelman]

Downgrading to 0.10.1 fixed for me.
Updating Apollo Client 1.2.2 did not fix.

I can see in my dev tools that a request is being fired when my props are updated and is getting an appropriate response, but props.data.loading is never set to false and props.data never gets my queried data as one of its fields.

[helfer]

@NickDubelman is that irrespective of the react-apollo version used? Can you determine whether this is due to react-apollo or apollo-client?

[NickDubelman]

I believe it is due to react-apollo. I was using 1.x react-apollo when I tested Apollo Client 1.2.2. I imagine Apollo Client 1.2.2. would work with react-apollo 0.10.1.

[helfer]

Ok, I think a reproduction would be really great for this. It looks like we still don't have one. Would you be able to put one together using react-apollo-error-template @NickDubelman? :pray:

[NickDubelman]

I will try over the next few days!

[advance512]

I am facing this issue as well. It certainly happens in one specific query (possibly others too), and it does not have an array.

Weird.

query someObject (
  $campaignId: Int!
  $testerId: Int!
) {
  campaignContestant(campaignId: $campaignId, testerId: $testerId) {

      id
      uuid
      testerId

      settings {
        jsonObject
      }
  }
}

[helfer]

@advance512 if you like, you could also try to make a reproduction!

[advance512]

The issue is sporadic, hence I'd guess it is related to apollo-client's data fetching state machine. It also means it is quite hard creating a reproduction, even more as you'd need some sort of GraphQL server and front end framework to work with and show the issue.

For now I've done what others have done, downgraded to 0.10.1.

[abergenw]

Not sure if it's related to this issue, but this happens when a react component is "remounted" with different variables for the query. While not standard practice, it happens e.g. when including some content in a component's state, and the state is updated with new content which happens to be the same component only with different props/variables. In this case a remount occurs.

This line seems to be what's causing problems (the listener gets removed prematurely):

https://github.com/apollographql/apollo-client/blob/master/src/core/ObservableQuery.ts#L125

[janiukjf]

@abergenw This is exactly how we are using components with apollo and are seeing the same behavior as described. Any suggestions on a better, more standard approach?

UPDATE: It helps to check which version you're on. I discovered this issue was already resolved for my case. I was just a few versions behind. Nothing to see here. Move along...

[advance512]

@janiukjf - what version are you using, that resolved the issue?

[janiukjf]

@advance512 I had to update both apollo-client and react-apollo to versions 1.4.0 and 1.4.2 respectively.

[srosset81]

Updating to latest apollo-client and react-apollo also solved the issue for me :tada:

[helfer]

Great, in that case I'll close this issue 🙂

[nbushak]

This is still happening for us, even with the latest versions of react-apollo and apollo-client (1.4.2). I even tried downgrading apollo-client to 1.4.0 to match @janiukjf's experience, but that also didn't work. The affected component/query does not use variables.

[nbushak]

I also think that @abergenw's comment is a red herring. I tried logging inside the removeQuery() call, and that wasn't called for us. I also commented out the unsubscribe() call and that didn't fix our problem.

[helfer]

@nbushak ok, we'll open it back up then!

[abergenw]

@nbushak in that case I don't know what's going on. The situation I described can easily be reproduced and fixed by removing the premature removal of the listener (the removeQuery() call).

[bmpieretti]

Our team is having the same issue but difference circumstances. Anytime a route change happens during the polling process, the loading and data objects we need never get evaluated, although we get a 200 and response in the network tab. We have updated to the current versions of both react apollo and apollo client, but it is still a problem.

[helfer]

Can I get a show of hands for how many people are still seeing this issue or a similar one? Please vote 👍 if you're having the issue.

If one or more of you could provide a reproduction using the react-apollo-error-template, that would also help us greatly speed up the process of finding and fixing this bug.

[dylanscott]

@helfer I've put together a minimal repro of this. I didn't notice you mentioned the react-apollo-error-template project but hopefully this should be similar enough - my repro was created with create-react-app and is pretty small. You can find it here.

I go into some detail about how to reproduce the issue in the README, but it appears to be caused by some interaction between

• Using polling with the pollInterval option
• Having multiple copies of the same GraphQL container component rendered on the page at one time
• Triggering a re-render on those GraphQL components while a polling request is in flight

Let me know if you have any trouble reproducing this. I tried to make it pretty easy.

[advance512]

Superb work, @dylanscott!

[smooJitter]

Lord... my very first graphql container and this is what I get.🤦🏾‍♂️. I'm using recompose branch and renderComponent to handled data availability logic. The data is there but like every one else, networkloading is stuck at 1. I'll try upgrading my tooling. I passing a simple query with no special options or parameters. Nevertheless, I'm importing default export stateless components. This allows me to use generic names, e.g., import viewComponent from '...' export default compose(...)(viewComponent). The component attached to the viewComponent environment depend on the module. Perhaps my use case fits @abergenw noted conditions. In any case, throughout the app I'm importing many components as viewComponent, I've only tried loading graphql data into one, my very first graphql component. I'm looking forward to seeing how this gets resolved. I'm startled this is happening while just getting my feet wet, the polling and all that stuff is over my head at this's point.

[smooJitter]

Resolved: I'm using redux-persist. I added 'apollo' to the blacklist all is well.

[semeleven]

When I refetch, after server error, loading not will be true, why? Have network request, but loading === false.

[johannchen]

I am using react-apollo 1.4.8, it works for the initial load, but when the props change to trigger refetch, loading is still false. same problem as @Ralf8686

[heysailor]

Similar for me. I have a component that I mount in when data is required, and it's often mounted with different variables. Just as @abergenw mentions. The network request succeeds but the component is stuck in loading state.

It takes a further (unrelated) interaction from the user - in my case, tapping on a map elsewhere - to come out of the loading state.

I can get around it rather horribly by setting an interval which updates a sham state parameter regularly with Date.now() until the loading prop turns true.

[tomitrescak]

Hi, I have another reproducible case.

I have noticed that this happens after I call resetStore.
My workflow is:

1. When logOut -> resetStore
2. logIn ... no component will update to loading = false

To reproduce:

1. go to: http://staging.claraworld.net
2. use: t.[email protected] / apollo123 as access data
3. log out
4. log back in ... voila, everything is stuck on LOADING

Reset store line is in client.min.js:1920

logout() {
        apollo_1.default().resetStore();
        this.profile = null;
        helpers_client_1.RouterUtils.go('/');
    },

And the loading code is client.min.js:11745

if (notificationData.loading || scheduleData.loading) {
        return React.createElement(loading_view_1.default, null);
    }

[jbaxleyiii]

@tomitrescak I wonder if this is actually an interop issue between react-apollo and apollo-client. I think when reset store happens, the react tree isn't rerendering correctly. Could you create a simple reproduction for me to take a look at?

[tomitrescak]

@jbaxleyiii ... I tried downgrading apollo-client and all goes back to normal at 1.7.0 1.8.0 (I did not try every version, just minor ones).

I am not sure how to create a minimal repro, I am affraid that what I have posted is good as it gets :/

[dylanscott]

@helfer were you able to reproduce the issue with the repro I linked? I just upgraded it to the latest apollo-client and react-apollo releases and can still reproduce the issue. This seems like a pretty minimal repro case, which is what you asked for.

[stretchkennedy]

We're seeing a case of this where APOLLO_QUERY_STOP is sometimes but not always dispatched before APOLLO_QUERY_INIT for the same queryId, and it's only happening for one query. I haven't been able to create a minimal repro or figure out what's special about that query yet, unfortunately.

[emmenko]

Hey guys, we are also experiencing the same issue (logout -> resetStore -> login) on version 1.9.0.
However I downgraded the version to 1.8.1 and it seems to work again. I guess some kind of regression introduced in 1.9.0?

I'm also using [email protected], but changing the version there does not seem to influence the result.

[jimthedev]

Same as @emmenko.

Using [email protected] in combination with [email protected] works.

As soon as you upgrade to 1.9.0 this issue starts happening. Here is the diff between those: https://github.com/apollographql/apollo-client/compare/v1.8.0...v1.9.0

edit 1.8.0, not 1.8.1 (it doesn't exist)

[bylevel]

I have same problem.

1. When logOut -> resetStore
2. login
3. When data == last data ... no component will update to loading = false

if data != last data , no problem.

So, I try get server time.

query adminInfoQuery {
  admin {
    id
    username
    realname
    extendsPermission
  }
  serverInfo {
    now
  }
}

[bradleyayers]

I actually had a really similar issue to this, but I was using react-apollo and my component was getting stuck in "loading=true" state. Turns out the problem was that I hadn't specified notifyOnNetworkStatusChange=true (by default it's false). So in the graphql container I had to set { options: { notifyOnNetworkStatusChange: true } }.

[tomitrescak]

Yeah, I was just about to post this, had similar issue and that solved it!

[windgaucho]

@bradleyayers solution work form me too

[parohy]

Facing the same issue. When I open a certain scene, I have a swiper with same components but different query variables. On all pages in the swiper I am stuck on loading: true and no data returned.
Tried it without variables as well, same result.
Applied the downgrade to 1.8.0 and with notifyOnNetworkStatusChange, no success. Debugger prints APOLLO_QUERY_RESULT for all pages.
This is strange, because on other screen I have a list of components where I do query each with different variables and it is working even when I refresh or change its content during runtime.

[emmenko]

Setting notifyOnNetworkStatusChange: true does seem to help. Thanks 👍

[jahed]

While @bradleyayers' workaround might work, it'd be nice to have an actual solution to this. I don't think that's the original intention of notifyOnNetworkStatusChange. Also, having to set that option on every query isn't great.

I've been looking at my particular case (similar to others using resetStore), and have a feeling it's to do with how QueryObservable, QueryRecycler and QueryManager interact. notifyOnNetworkStatusChange is used to decide if a query is still loading so it's probably related.

Still looking into it.

[jahed]

I'm pretty sure now that it's a caching issue. But I don't know enough to provide a fix.

When the graphql HOC renders, it gets the data from QueryManager.getCurrentQueryResult, which tries to get the query result and consumes any errors. If there are any errors, it returns an empty data and partial: true. When you're using the network caching, the partial is remapped as a valid result and loading is set to false, otherwise, loading is set to true, causing the infinite loading as there are no remaining events to change state on.

The reason getCurrentQueryResult is throwing an error in my case:

Error: Can't find field entityBySlug({"entitySlug":"Map","worldSlug":"game0"}) on object (ROOT_QUERY) {
  "current_user": null,
  "worldBySlug({\"slug\":\"game0\"})": {
    "type": "id",
    "id": "World:2",
    "generated": false
  }
}.
    at readStoreResolver (readFromStore.js:41)
    at executeField (graphql.js:74)
    at graphql.js:31
    at Array.forEach (<anonymous>)
    at executeSelectionSet (graphql.js:26)
    at graphql (graphql.js:20)
    at diffQueryAgainstStore (readFromStore.js:73)
    at readQueryFromStore (readFromStore.js:18)
    at QueryManager.getCurrentQueryResult (QueryManager.js:652)
    at ObservableQuery.currentResult (ObservableQuery.js:72)

It's trying to find a result from the cache that doesn't exist and falling through the try-catch. Which may be intentional, as it can retry until it is in the cache,

But, the graphql HOC doesn't subscribe to the Redux store, it seems to subscribe to the Apollo Client (via QueryObservable), so once those queries do resolve and they get saved in the store (as everyone's already mentioned), the HOC isn't told so it just goes on, loading forever.

That's what I'm thinking anyway. I can't figure out how QueryObservable is being wired up to trigger re-renders when the data does come in. When the data is stored, the HOC explicitly decides not to rerender based on its unrelated props.

That's as far as I'll go here. Hope it helps someone with broader knowledge in how this is all wired up. Or maybe I'm completely wrong. 🤐

[Spoki4]

I think it's happening becouse we clearing store. I tried clear store two different code

apolloClient.resetStore()

and in main reducer

const appReducer = combineReducers({
    ...
    apollo: apolloClient.reducer()
})

export default (state, action) => {
    if (action.type === "LOGOUT")
         state = undefined                     //  <------- this method
    return appReducer(state, action)
}

In apollo-client-devtools I saw a cache of my requests. But in redux, we didn't have data.
empty branches of apollo state.

but in devtools i saw this(i tried toggle the left-side tabs for relaod data. Nothing.).

Maybe it's a bug in devtools.

And main, If i don't clear store, it's work fine. without inifnity loading.

[ducngtuan]

One thing i want to note here too, is that when i tried to do the same thing in Vue (with Vue-Apollo which use Apollo Client underneath), there is no infinite loading when I do logout (resetStore) -> login -> homepage. And I didn't use notifyOnNetworkStatusChange for the Vue example either. I don't know if Vue-Apollo does something different than React-Apollo when hook up the query with the component or was it the different between Vue and React. In the mean time notifyOnNetworkStatusChange seem like the only fix.

[jinxac]

it looks like regression introduced in ^1.9.0. I was earlier using 1.4.1 on which it worked perfectly fine.

I updated my packages yesterday to and moved apollo-client to 1.9.1 and was able to see this issue after client.resetStore(). After reading comments in this section tried downgrading to 1.8.1 and it works fine.

[AlexMost]

Also had this issue in apollo-client:1.9.2. This issue was reproducing each time when query returned an empty list as a result. (productsQuery.products was empty). Everything works ok on page reload. Downgrade to 1.8.1 fixed that. Finally solved this issue with notifyOnNetworkStatusChange: true in 1.9.1, but feels like it is a workaround.

[krinoid]

I also encountered this bug, and setting notifyOnNetworkStatusChange: true in 1.9.1 didn't always work (but bug seemed to occur less frequently). Similarly to @AlexMost, downgrading to 1.8.1 solved the issue.

[mitjade]

I can also confirm that client.resetStore() causes this issue. Tested on 1.9.1 and 1.9.2.
notifyOnNetworkStatusChange: true fixes the issue in this two versions and works in 1.8.1 with no changes required.

If I use apollo-logger I see that the query get's successfully executed, but component does not refresh.

[mitjade]

I created a minimum possible reproduction scenario here: react-apollo-error-template.

I use react-router-dom v4.2.2 to navigate between pages, apollo-client v1.9.2 and react-apollo v1.4.15.

Steps to reproduce:

• Start app
• Go to Logout Page
• Press Logout button

Logout does client.resetStore() and then history.push('/'). You can then see the Loading... on Home page. If you Press the Home link at the bottom, component does refresh and works ok from then on. If I comment out client.resetStore() on Login page, all works ok.

[dude-awesome]

I have exactly the same issue. it only happens sometimes for me if the result will be an empty array.

"dependencies": {
    "apollo-client": "^1.9.2",
    "graphql-tag": "^2.4.2",
    "history": "^4.7.2",
    "html-webpack-plugin": "^2.30.1",
    "idb": "^2.0.3",
    "lodash": "^4.17.4",
    "path": "^0.12.7",
    "react": "^15.6.1",
    "react-apollo": "^1.4.15",
    "react-dom": "^15.6.1",
    "react-router": "^4.2.0",
    "react-router-dom": "^4.2.2",
    "semantic-ui-react": "^0.72.0",
    "serviceworker-webpack-plugin": "^0.2.3",
    "webpack": "^3.5.5",
    "webpack-dev-server": "^2.7.1"
}

When I take a look into my browser network console I always get the result like I´ve expected but the loading state of the query sometimes just stays true even when the result is still served.

[mitjade]

@helfer Could you please confirm, if my reproduction scenario is good enough, or do you need some additional info.

[mxmtsk]

It stays true for me too when the result contains and empty array (same as @rlech) Using "react-apollo": "^1.2.0", and React Native.

[jasonmorita]

@krinoid 's fix of using 1.8.1 worked for me as well.

[mattfysh]

Anyone know how/why notifyOnNetworkStatusChange works?

[nbushak]

Can we drop the "reproduction-needed" label here? There are multiple ones listed at this point.

[stubailo]

Yeah, thanks for bringing that up. I'll see if we can prioritize this issue. Does anyone have lead on a fix/underlying cause?

[nbushak]

Definitely a fan of prioritizing this one :) At this point this issue is the historical #1 issue by number of comments for both the apollo-client and react-apollo github projects. I spent a few hours digging into this yesterday, but it's tough as someone without an intimate knowledge of apollo internals and the apollo-client/react-apollo state machine. I also upgraded to Apollo 2.0 to no avail.

https://github.com/apollographql/react-apollo/issues/976 has a pretty clear repro (which matches my experiences), although I imagine there are other situations where this happens as well.

See https://github.com/apollographql/react-apollo/issues/170, https://github.com/apollographql/react-apollo/issues/976 and a bunch of potential dupes as well: perhaps https://github.com/apollographql/react-apollo/issues/807, https://github.com/apollographql/react-apollo/issues/890, and more. It looks like a previous version of this issue was fixed in https://github.com/apollographql/react-apollo/issues/718, but came back again?

[jbaxleyiii]

@here I'll be taking a look at upgrading these reproductions to 2.0 and digging into it again. I agree we should make sure its working for the 2.0. Will anyone commit to trying out beta's for quick feedback on shipped builds?

[jbaxleyiii]

I've also setup a milestone for the 2.0, if you have other issues that are critical please add them to that milestone for review! https://github.com/apollographql/apollo-client/milestone/9

[nbushak]

Actually, looks like I spoke too soon, it's possible I did something wrong and didn't upgrade to Apollo 2.0 on my other project correctly

I went through the effort of forking the example in https://github.com/apollographql/react-apollo/issues/976 and it seems that it no longer repros in Apollo 2.0. See https://github.com/nbushak/apollo-reset-issue for anyone interested. Maybe this issue will be fixed on its own in 2.0? It sounds like the next step here is for folks to try to repro in 2.0? I'll try to upgrade my main project to 2.0 as well to see if it stops reproing everywhere.

[dylanscott]

I can confirm that the issue in dylanscott/apollo-repro appears to be fixed after upgrading to the apollo-client 2.0 beta.

[mitjade]

I can also confirm that loading issue is gone in apollo-client 2.0 beta. But store still does not get reset as mentioned in https://github.com/apollographql/react-apollo/issues/807 and https://github.com/apollographql/react-apollo/issues/890.

[jer-sen]

For me it seems that in 2.0, after an error (error not null and networkStatus at 8), the status of the request is not updated by a refetch (and the component not rerendered). Even after loading successfully the refetch, the error remains...

[stubailo]

@jay1337 yeah, there might be a few bugs still during the beta process. Would you mind opening a new issue for that new problem?

[jer-sen]

@stubailo there is already one but you closed it with your bot : #1622

[jbaxleyiii]

@jay1337 is that same error happening exactly as described on the 2.0? Without a reproduction we won't able to fix it very easily

[jbaxleyiii]

@jay1337 that error should be fixed in the latest beta!

[jer-sen]

@jbaxleyiii the error is still there.

Basically, when there is a network error, the queryObservable is removed from graphql wrapper object (in react-apollo.browser.umd.js). Any refetch only update Apollo store but does not trigger a rerender of the components.

I found a workaround by adding a retry function to the data prop passed to the wrapped component in function dataForChild:

else if (error_1) {
        assign(data, (this.queryObservable.getLastResult() || {}).data, { retry: () => {
            this.unsubscribeFromQuery();
            this.queryObservable = null;
            this.previousData = {};
            this.updateQuery(this.props);
            if (!this.shouldSkip(this.props)) {
                    this.subscribeToQuery();
            }
        } });
}

Then I can call this.props.data.retry() from the wrapped component to retry to fetch the data, and the component will receive new data prop without an error (if a valid response is received from the server).

This does not solve the polling issue (definitely stopped by an error).

Maybe this can help people facing other issues : #1622 #1601 https://github.com/apollographql/react-apollo/issues/642

[jbaxleyiii]

@jay1337 can you open a new issue for that issue with a reproduction? And add it to the 2.0 milestone? Thanks!

[finian]

The notifyOnNetworkStatusChange: true solution is not ideal. If we have a paginated list and try to load more data with fetchMore, the data.loading will be true and the whole list will be in loading state (Expect fetchMore not to trigger data.loading)

[bradleyayers]

@finian loading doesn't imply an initial load, it just implies some loading is happening. It sounds like you want to look at the exact networkStatus instead — http://dev.apollodata.com/react/api-queries.html#graphql-query-data-networkStatus.

[finian]

@bradleyayers Thanks. networkStatus is exactly what I want.

[leizard]

I have the same issue and notifyOnNetworkStatusChange: true works for me too, maybe it should be put in the official doc.

[leosurwiki]

Same issue, loading never set to be false in some cases while I have set notifyOnNetworkStatusChange.

Three nested graphql containers, structure like:
A
(react navigator)
/ \
B C
(both are screens)
Some nodes are shared between queries in A and B.
When I shutdown the server and refresh the client, I got network status log like:
[A:1, B:1, C:1, B:8, A:8, B:1, C:1, C:8]

This issue was solved by downgrading apollo-client to 1.8.1. So, I think it should be a bug.

[flippidippi]

When I use notifyOnNetworkStatusChange: true is works for me also and loading gets updated to false. Without that loading stays true forever.

[juank11memphis]

Any update on this issue, I tried notifyOnNetworkStatusChange: true but it didn't help, I have container component that is fetching 3 queries, if one has errors then loading never gets updated to false

[deanmckee]

Anyone have a fix for this issue? I also an suffering from intermittent loading flag issues on the latest 2.0 release (it seems like these loading flag bugs have been around for nearly a year). As others have said it seems to trigger when a nested HOC has a property change and is interacting with the cached values (I don't see the queries on the server side when this happens). I've tried the notifyOnNetworkStatusChange: true solution but it doesn't seem to eliminate this completely.

I may end up downgrading to the 1.8.1 version and giving up on 2.0 until this is resolved.

[ShepelievD]

Worked notifyOnNetworkStatusChange: true in verison 2.2.2

[juank11memphis]

I tried notifyOnNetworkStatusChange: true again but it didn't help. @ShepelievD do you have a container component with multiple queries?

[iKonrad]

Can confirm this is still reproducible on the 2.0.0-rc.7 version.

[ShepelievD]

@juank11memphis yes, I do

[juank11memphis]

@ShepelievD Would it be possible for you to share some code so we can figure out what are we doing wrong?

[batjko]

Still seeing this issue with react-apollo 2.0.4.
notifyOnNetworkStatusChange: true does not work in our case either.

The error on the console is the one that my back-end service sent back to graphql for one of the fields I am querying for (the other fields resolve fine, but this field gets set to null, as expected.
However, I would also expect the client to set loading to false, so I can at least deal with the rest of the returned data.

[mtsap]

I think I just hit that bug also.
Component TodosList queries local state for the loggedin boolean.
When that gets true it renders TodoListSub that in its turn renders data coming from a subscription.
If I render TodoListSub on its own it works as intended.
But if I render it through the TodosList component the loading variable gets stuck to true

Code for TodosList:
```` import React from "react";
import { Query } from "react-apollo";
import gql from "graphql-tag";
import TodoListSub from "./TodoListSub";

const IS_LOGGED_IN = gql query { loggedIn @client } ;

const TodosList = () => (
{({ data, loading, error }) => {
console.log(data);
if (loading) return "Loading...";
if (error) return Error! ${error.message};
if (!data.loggedIn) return

Youy are not loggedIn

;
return ;
}}

);

export default TodosList;
````

Code for TodoListSub:
````
import React from "react";
import { Query, Subscription } from "react-apollo";
import gql from "graphql-tag";
import Todo from "./Todo";

const SUBSCRIPTION_GET_TODOS = gql subscription OnTodoAdded { AllTodos { id text added } } ;
const TodosListSub = () => {
return (
{({ data, loading, error }) => {
console.log(data, loading, error);
// if (!loggedIn) return You are not logged in;
if (loading) return "Loading...";
if (error) return Error! ${error.message};
return data.AllTodos.map(td => );
}}

);
};

export default TodosListSub;
````

pakcage.json deps
"dependencies": { "apollo-cache-inmemory": "^1.2.1", "apollo-client": "^2.3.1", "apollo-link": "^1.2.2", "apollo-link-http": "^1.5.4", "apollo-link-state": "^0.4.1", "apollo-link-webworker": "^0.1.3", "apollo-link-ws": "^1.0.8", "firebase": "^5.0.3", "graphql": "^0.13.2", "graphql-subscriptions": "^0.5.8", "graphql-tag": "^2.9.2", "graphql-tools": "^3.0.1", "react": "^16.3.2", "react-apollo": "^2.1.4", "react-dom": "^16.3.2", "react-scripts": "1.1.4", "subscriptions-transport-ws": "^0.9.9", "worker-loader": "^1.1.1" }

[AndrewPrifer]

Just hit this bug as well. My scenario is very similar to that of @cyrus-za and @oliviertassinari from https://github.com/apollographql/react-apollo/issues/170. I managed to isolate the kinds of updates that result in loading being stuck to true and data not updating; Maybe the following will help someone with more intimate knowledge of Apollo internals track down the bug.

We are using react-apollo 1.4.16 and apollo-client 2.3.5.

Our scenario:
We use react router 4 and each page is wrapped in graphql(). When the page mounts, the query is executed with variables supplied to the page. We don't currently use id-based cache normalization, but the default query path based one.

I isolated 3 conditions that are necessary for it to be stuck:

1. I navigate away from a page and then back again with a different set of variables supplied to the page.
2. The query results are the same as those from the previous page visit. If the results are different there is no problem.
3. There is no other page visit between the two, which returns a different query result. For some reason, if I navigate away, then back, and the resulting query returns a different result than the previous, then even if a subsequent page visit does lead to the same query result as the first one, it works.

Like others have noted before me, the queries execute without errors, the data is in the cache, it is just that when the data is loaded my page is not updated by the graphql() HOC. And notifyOnNetworkStatusChange: true did work for me, probably because it triggers updates to the component even if data loading doesn't.

[msmfsd]

+1

[vasilich6107]

This is very annoying bug, it still happens(

[tnrich]

Still occurring for us as well. Hopefully we'll be able to make a reproduction..

[austincondiff]

I am having the same issue. It only happens when I perform a second query different from the first that yields the same result as the first.

[AndrewPrifer]

@austincondiff I noticed the same thing (see my comment above).

[chris-guidry]

In react-apollo 1.4.x the notifyOnNetworkStatusChange: true bandaid works, but I didn't want to update every component to include that option (it didn't seem to work as a default option for the entire app). I decided to upgrade to react-apollo 2.2.0 and haven't experienced the issue since.

[austincondiff]

@chris-guidry I still experience the same issue in react-apollo 2.2.0

[austincondiff]

@andrewpeterprifer did you ever find a solution of workaround?

[AndrewPrifer]

@austincondiff notifyOnNetworkStatusChange: true worked for me as well. Given we have the same reproduction, I think it will work for you too.

[austincondiff]

@andrewpeterprifer I can confirm that it did work! 🙌 Thanks a lot!

[simeonpashley]

This still occurs with the latest version when using composed graphql from react-apollo for a component. I don't know if this also applies to the related Query
[email protected]
[email protected]

As mentioned above, adding notifyOnNetworkStatusChange: true to the options still fixes this issue of data.loading not being set to false in some instances.

    options: () => ({
      errorPolicy: 'all',
      fetchPolicy: 'network-only',
      notifyOnNetworkStatusChange: true,
      ssr: false,
    }),

[michaelolo24]

I'll make a note here that the issue still persisted for me when using clearStore, but was fixed if I switched to resetStore. I expect that this is due to the fact that clearStore doesn't actually cause a network status change since a refetch request isn't made for clearStore?

[selmansamet]

I've also encountered this bug on mutations, not just queries :/

[janmisek1]

Same behavior here.

    "apollo-cache-inmemory": "1.5.1",
    "apollo-client": "2.5.1",
    "apollo-link": "1.2.6",
    "apollo-link-context": "1.0.12",
    "apollo-link-error": "1.1.5",
    "apollo-link-http": "1.5.9",
    "react": "16.8.2",
    "react-apollo": "2.3.3",

We use apollo as HOC.

fetchPolicy: 'no-cache', or notifyOnNetworkStatusChange: true, solved the problem.

[heysailor]

For those reading this thread, and using react-apollo: loading state is not
updated for all types of data fetches, and hence query components do not
re-render. The docs are here:
https://www.apollographql.com/docs/react/data/queries/#inspecting-loading-states

You can get fine-grained loading state from the networkStatus parameter.

On Wed, 2 Oct 2019, 14:42 Jan Míšek, [e-mail] wrote:

Same behavior here.

"apollo-cache-inmemory": "1.5.1",
"apollo-client": "2.5.1",
"apollo-link": "1.2.6",
"apollo-link-context": "1.0.12",
"apollo-link-error": "1.1.5",
"apollo-link-http": "1.5.9",
"react": "16.8.2",
"react-apollo": "2.3.3",

We use apollo as HOC.

fetchPolicy: 'no-cache', or notifyOnNetworkStatusChange: true, solved the
problem.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/apollographql/apollo-client/issues/1186?email_source=notifications&email_token=AAUWLX4ODZNTKXDIB24DCIDQMQ7GFA5CNFSM4C4U5VUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEADXFXA#issuecomment-537359068,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAUWLXYUAM4IERPZGGFLKDLQMQ7GFANCNFSM4C4U5VUA
.

[hinok]

I can confirm that this bug still occurs on

11:37 $ yarn list --depth=0 | grep apollo
├─ @apollo/[email protected]
├─ @apollo/[email protected]
├─ @apollo/[email protected]
├─ @apollo/[email protected]
├─ @apollo/[email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]

In my case it was @apollo/react-hoc and notifyOnNetworkStatusChange solves the issue.

import { graphql } from '@apollo/react-hoc';

[JimmyCheng]

I confrim this bug still occurs on
npm list --depth=0 | grep apollo |--@apollo/[email protected] |--@apollo/[email protected] |[email protected] |-- [email protected] |-- [email protected] |[email protected] |[email protected] |[email protected]

In my case I add notifyOnNetworkStatusChange solves the issue.

useQuery(getXXXXQuery, { variables: { .... }, notifyOnNetworkStatusChange: true });