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?

[EDIT]: I can report that it only happens on queries that return arrays of fields

[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 #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 #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?

[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 { Query } from "react-apollo";
import gql from "graphql-tag";
import TodoListSub from "./TodoListSub";

const IS_LOGGED_IN = gql`
  query {
    loggedIn @client
  }
`;

const TodosList = () => (
  <Query query={IS_LOGGED_IN}>
    {({ data, loading, error }) => {
      console.log(data);
      if (loading) return "Loading...";
      if (error) return `Error! ${error.message}`;
      if (!data.loggedIn) return <p>Youy are not loggedIn</p>;
      return <TodoListSub />;
    }}
  </Query>
);

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 (
    <Subscription subscription={SUBSCRIPTION_GET_TODOS}>
      {({ 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 => <Todo key={td.id} todoFromProps={td} />);
      }}
    </Subscription>
  );
};

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 apollographql/react-apollo#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?

[sametcodes]

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, ***@***.***> 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 <#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 });