useQuery Hook always return true on loading state - previous issue needed to be reopened

[ajhool]

There is a closed issue that is still persisting. Multiple requests to reopen the issue have not been responded to so I'm assuming that notifications for closed issues are not being tracked and am creating a new issue to point to that closed issue.

#3361

[nmklotas]

this happens for me as well on 3.1.3 version of @apollo/react-hooks"

[kaatt]

Related: #3488 #3361 #3425 #3090 #2899

[SethGreylyn]

I've had this issue appear intermittently (~1/10 loads) for a particular query, which is evidently resolved by setting fetchPolicy to no-cache.

[kaatt]

@SethGreylyn Everyone's using that fetchPolicy workaround but we shouldn't have to.

[davetapley]

So I believe we're seeing this, albeit with a subscription and not a query.
However the fetchPolicy is not working for us 😞

As a more general question:
For a subscription hook should it ever be the case that onSubscriptionData is called, has subscriptionData, and yet the hook has loading of true and data of undefined? Because that's what we're seeing.

[Discordius]

We are also running into this problem for queries that are have ssr false and that are hydrated from a server-response. This is currently preventing us from upgrading to anything beyond 3.0.0

[dustinsgoodman]

Can confirm I'm seeing the same issue. Looks like loading is never reset back to false once the query is loaded from the cache.

[dustinsgoodman]

Additional info I think might be related is it's potentially an issue with the apollo cache having issues hashing objects used to filter queries. Let's say I have filters A, B, C, D defined as:

const filterA = { x: [] };
const filterB = { x: [1] };
const filterC = { x: [2] };
const filterD = { x: [1, 2] };

If I start with filterB and switch to filterA or filterD, the loading state resets correctly. However, if I go from filterB to filterA, I get the issue described in this issue where the loading state never resets back to false. Hope this is helpful.

[kaatt]

@dustinsgoodman That seems to be correct. If you could make a small repo or codesandbox that repros this issue, it'd be a great help for the maintainers and might push them into looking into this finally.

[dylanwulf]

Yeah, I've been watching this repo for a while now and I can confirm that providing a runnable reproduction significantly increases the chances of the issue being fixed.
Also I think this react-apollo repo is going to be deprecated in the future, it looks like all the code is moving to the apollo-client repo.

[mpgon]

Indeed but that is the case for any repo. The problem here is that this happens very seldomly and apparently under very specific circumstances. Even in prod with millions of requests, it sometimes goes 2 days without occurring to multiple times in one day.
My hotfix at the moment is listening for long "pending" requests and calling "refetch" after a certain timeout.

[dylanwulf]

If you decide to report a bug, then you have taken on the responsibility of figuring out exactly what circumstances are necessary to reproduce that bug. The maintainers can't just magically know exactly what causes a bug after reading a few sentences.
If I were to guess, I'd say #3425 is the most likely culprit here.

[mpgon]

I don't necessarily agree. You should definitely try, but even if you can't pinpoint what's causing the bug, I think it's fair to let the community know/open a discussion about it. I agree with the part that it shouldn't rest solely on the maintainers shoulders. But this is clearly happening to a lot of people, so raising awareness in a respectful manner is ok too.

[dylanwulf]

@mpgon Ok fair point. I just think we shouldn't expect the maintainers to do anything until someone provides a reproduction

[ghost]

For now I think we can put fetchPolicy : no-cache in the defaultOptions in test cases instead of in the actual useQuery to avoid pollute the production.

[VictorGaiva]

I believe that this issue might be coming from the fact that the flag loading isn't enough for all the use cases. The ideal would be to have a status object which keeps track of the current state of the query. I say a Object, not a string, so we can keep track of more than one piece of information.

My take on this would be something like this:

status: {
        cache: 
            'valid' |       // The cached data for the current query is valid
            'invalid' |     // The cached data for the current query is invalid
            'disabled',     // The cache is disabled for the current query
        network:
            'idle' |        // There is active communication for the current query
            'processing' |  // The current query is being processed by Apollo, and it might fetch data from remote, local or cache
            'fetching' |    // Data is currently being fetched from remote
            'failed',       // For some reason it was not possible to communicate with remote. see 'error' field.
        data:
            'initial' |     // The data holds the initial value for the data. Might be 'undefined' or the initial value set for the local data (see @client)
            'empty' |       // No data is being held
            'invalid' |     // Current data is invalid (cache got invalidated)
            'cached' |      // The data is taken from cache
            'remote',       // THe data is taken from remote
    }

[Amirault]

same pb on :
"apollo-cache": "1.3.4",
"apollo-cache-inmemory": "1.6.5",
"apollo-client": "2.6.8",
"@apollo/react-components": "3.1.5",
"@apollo/react-hoc": "3.1.5",
"@apollo/react-hooks": "3.1.5",

[grydstedt]

This seems to be a race condition on updating the cache. No other resolution do this?

[smeijer]

This seems to be a race condition on updating the cache. No other resolution do this?

Don't use the loading state. Check for the presence of your data instead.

[dustinsgoodman]

@kaatt I'm sorry I haven't had time to make a proper sandbox to prove this. As I was experimenting in sandbox, I left out apollo cache and link state which were the other common factors I'm seeing with other people's posts and was unable to repro. I think the issue lies when some state/cache manager gets involved and the loading flag not updating appropriately on a successful cache read.