apollo-client: skip in useQuery hook doesn't work as expected

Just in case, this is not fixed in 3.3.16.

As a work-around, I’m using fetchPolicy: skip ? 'cache-only' : 'cache-first', but this is a nasty bug.

Still happening in 3.6.9, even with skip: true.

When I set skip: true the request is made, but the data isundefined. I think it should skip completely the request.

I can confirm it is still not working properly in “^3.5.10”, query is being executed right away. Is there another open issue, why is this closed ?

I’m using Apollo 3.5.5 and I’m experiencing the same issue. Passing a literal boolean value to skip works, but passing an expression that evaluates to boolean fails.

This works

const { loading, error, data, refetch } = useQuery(GET_REPOSITORIES_OF_ORGANIZATION, { 
  variables: {
    organizationLogin
  },
  skip: true
})

This doesn’t work

const { loading, error, data, refetch } = useQuery(GET_REPOSITORIES_OF_ORGANIZATION, { 
   variables: {
     organizationLogin
   },
   skip: organizationLogin === '' ? true : false
})

Hard-coding a value to that field negates its usefulness by making it unable to programmatically change when a query should or should not run.

I don’t understand exactly why this has been closed

Still a problem at “@apollo/client”: “^3.5.6”

Still a problem "@apollo/client": "^3.4.16".

This is happening for us as well using 3.0.2.

+1. Ran into this issue today. As a work around, I added a $skip variable to my query and used the @skip(if: $skip) directive directly in my query.

skip also doesn’t work for me with the regular useQuery.

In my case, I’m using the hooks generated by graphql-code-generator, but I think that doesn’t influence the behavior so I’m saying it just as an FYI.

I guess I’ll have to resort to the useLazyQuery + useEffect solution.

I think this should be reopened. I am using skip: true, and we are getting errors that our queries are firing without variables. "@apollo/client": "^3.4.16". It has been going on for a while

@hwillson Should the issue be reopened due to many ppl still experiencing it?

The issue is still reproducible on 3.2.4

Seeing this here with 3.1.1. What’s the latest status?

I would recommend that folks open a new issue with a repro link for codesandbox. Probably the best way to get eyes on something.

3.2.2 seems fixed it for us

Same here, any news?

The is still breaking our app even with workaround. The behaviour should be to SKIP when fetchPolicy: “network-only”, skip: true. Have all packages updated. Reopen the issue, please.

@hwillson - still seeing this as an issue in 3.0.1.

This is the commit that broke it, btw: https://github.com/apollographql/apollo-client/commit/9793b7d9159fae3e82f989be3db6d923fd811893

cc @hwillson, @sapkra ^

The onCompleted hook was a separate issue. Please reopen this.

I get the same bug. skip is not respected

Thank you! I am bit embarrassed that I haven’t really realized the difference untill now. But I’m going to hide behind the fact that the identical naming makes it a bit confusing for users 😃

Anyways, the apollo-composable useQuery have the “enabled” option that I can use instead.

Again, thank you and have a great day!

Hi @MrMossevig! I believe your case might be different - the useQuery hook of @vue/apollo-composable is a completely different api than the useQuery hook of @apollo/client.
I believe that useQuery hook just doesn’t have a skip option.

From what I can find, this issue appears to be fixed from v3.6.9 on. https://github.com/apollographql/apollo-client/issues/9673 appears to have been split out from this issue, which included a reproduction of the bug. This appears to have been fixed in https://github.com/apollographql/apollo-client/pull/9823, which was released in v3.6.9. In fact, if you open the reproduction and update the @apollo/client version to any version after v3.6.9, you’ll see the network request no longer fires when the query is skipped, as expected.

I’m inclined to say this has been addressed by #9823, however I need some help getting a reproduction and/or failing test to demonstrate the continued buggy behavior. I’ve created a branch with some additional tests around the skip behavior, but I’m unable to reproduce the problems talked about in this issue with the latest code in main. If there is some condition that isn’t covered either by the existing test suite, or the additional tests in my branch, please let me know so we can dig into this further. Thanks!

Hey all 👋 ! It seems there has been quite a few comments about this issue since it was initially closed. I’m going to go ahead and reopen since judging by its comments, it seems that an issue still persists. I’m hoping we can dig into this a bit further very soon. Thanks for your patience!

Still the case with skip: true, the query runs but the data is empty. I think the desired behavior would be not to run the query at all.

A solution I found was:

  const [loadQuery, { data }] = useLazyQuery(QUERY, { skip: !user });
  useEffect(() => {
    if (user) {
      loadQuery();
    }
  }, [user]);

This doesn’t load my query until after the user comes in. I left the skip in the first line, but I can probably remove it. @alchemist09 hopefully this helps you.

Skip is not available for useLazyQuery. So it doesn’t do anything. The reason why your query is not being executed is because that is the nature of useLazyQuery. It won’t execute until you call it. However it is not async.

A solution I found was:

  const [loadQuery, { data }] = useLazyQuery(QUERY, { skip: !user });
  useEffect(() => {
    if (user) {
      loadQuery();
    }
  }, [user]);

This doesn’t load my query until after the user comes in. I left the skip in the first line, but I can probably remove it. @alchemist09 hopefully this helps you.

We experience the same issue with3.2.4

@tobiaswaltl Sorry for the late response. Yeah, I think what you see with polling here might be another skip-related bug (The original bug didn’t include polling.), possibly the thing with undefined is yet another bug that we’ll have to look into. I’ll make a new open issue out of your comment so we can better track that - these kind of issues that combine multiple different similar-ish bugs over years are extremely hard to keep an overview on 😃

Chiming in here to say still broken 3 years later.

Version: 3.7.9

That’s a long time to be asking your user base to implement their own hacky work arounds in order to use your package.

I guess I’ll have to resort to the useLazyQuery + useEffect solution.

I’d recommend just conditionally setting the cache policy. It is a simpler (and thus better) workaround.

I think the person(s) closing it hasn’t really tested it under the different scenarios because the problem is quite prevalent now. What’s even more worrying is that subsequent releases of Apollo Client still ship with the same problem. Since the client relies on HTTP protocol to execute requests, a check needs to be placed before the request-making code executes. The main purpose for the check will be to determine if ‘skip’ is true.

We’re seeing this issue on 3.6.6 with

    fetchPolicy: 'cache-and-network',
    nextFetchPolicy: 'cache-first',

I really don’t understand how this issue keeps being closed without actually being fixed. I’ve generally found Apollo to be very reliable but we wasted a bunch of time tracking down this issue: it seems skip is sometimes respected, but likely fails on the second network query. We missed this failure in our initial testing – again, I wrongly trusted the @apollo/client code to be reliable

Not really sure why…

This works for me:

const [skip, setSkip] = useState(true);

  useEffect(() => {
     if (profile?.id) {
        setSkip(false);
     }
  }, [profile]);

  const { data: dataProjects } = useQuery(GET_PROJECTS, {
     variables: {
        onlyFeaturedProjectsOfId: profile?.id,
     },
     skip,
  });
  

This does not:

const { data: dataProjects } = useQuery(GET_PROJECTS, {
   variables: {
      onlyFeaturedProjectsOfId: profile?.id,
   },
   skip: !profile?.id,
});

Still happening to me on "@apollo/client": "^3.4.15"

Why does useQuery still parse the query when skip is true?

So we have to use a dummy query when unable to produce a query (we produce the query dynamically) even when skip is true:

query noQuery {
          nothing
        }

@hwillson Yes, please re-open this.

I’m using a similar work-around (using cache-only) to make sure fetch isn’t triggered, but this should be fixed.

@hwillson I believe this bug is about stopping the actual request, whereas it appears your fix only changes the behavior of onCompleted.

This should now be fixed in @apollo/client@3.0.1 (reference: #6589). Let us know if not - thanks!

If it is the exactly the same problem the fix is already merged and will come in the next release: https://github.com/apollographql/apollo-client/issues/6122#issuecomment-657906722 https://github.com/apollographql/apollo-client/blob/master/CHANGELOG.md