Apollo-client: @client(always:true) doesn't work 🐛

[nuragic]

Intended outcome:
As documented here, I expect my local queries resolvers to _always_ run.

Actual outcome:
They never run. 😕

How to reproduce the issue:
https://codesandbox.io/s/wom5lv5owl

Versions

"dependencies": {
    "apollo-cache-inmemory": "1.5.1",
    "apollo-client": "2.5.1",
    "apollo-link-http": "1.5.14",
    "apollo-link-ws": "1.0.17",
    "graphql": "14.2.0",
    "graphql-tag": "2.10.1",
    "react": "16.8.3",
    "react-apollo": "2.5.3",
    "react-dom": "16.8.3",
    "react-scripts": "2.1.8"
  },

Please let me know if you need extra info or if I could do anything to help.

Thanks! 💙

[benjamn]

This may be an issue with putting the @client(always: true) directive on a field that has its own selection set, rather than leaf fields, though I was under the impression both approaches should work:

export const CLIENT_QUERY = gql`
  query {
    apollo @client(always: true) {
      cool
      bug
    }
  }
`;

We (@hwillson and I) will investigate!

[supercranky]

I'm also having problems with @client(always:true) resolvers not being run when client is offline, for example in this query

query GetName($id: String!) {
    name(id: $id) {
      id
      name
      gender
      isFavourite @client(always: true)
    }
  }

it returns data straight from the cache (when offline). Or maybe that's expected behaviour?

[nuragic]

Thanks @benjamn! I also tried putting another string in the directive e.g. (lol: true) but nothing happens, no errors... (it should throw?)

@supercranky that seems related... can't tell exactly, it would be helpful to have a codesandox to reproduce as well

[Fatxx]

Also facing this using a mixed schema (remote and local)

    annotations {
      id: _id
      xmlIDTag
      content
      type
      position @client(always: true)
    }

Does trigger the first time, once gets cached it doesn't execute the resolver anymore.

[Fatxx]

@nuragic in your example even without (always: true) resolvers never gets executed which is super strange, I did some debugging and it seems well configured...

[nuragic]

@Fatxx Hi! Yes, that's true. In fact, the workaround I'm using right now to have a similar behaviour is to specify the fetchPolicy="no-cache" in my Query.

I've just updated the sandbox; you can see that by doing so, the resolver is now called:
https://codesandbox.io/s/wom5lv5owl

🙃

[Fatxx]

@nuragic I think with that solution we lose the offline ability since in my case I'm using mixed schema so other attributes which are already cached will be resolved on the server and I only want to execute the local resolver.

[Fatxx]

Seems to be also @supercranky problem

[Fatxx]

@hwillson any ideas?

[nuragic]

Right, in that case this specific workaround doesn't work. It was intended for client only queries like the one in the sandbox. I also have mixed server and client fields in some queries but there I'm not using this directive so far. In my case the @client fields are being calculated outside those fields' resolvers.

[Fatxx]

@nuragic Can you re-open please? I mean it's still an issue

[supercranky]

"always:true" should mean always as in always 😄

[Fatxx]

Yes other way it's just useless

[nuragic]

Ohh sorry! I hit the wrong button hehe

[sfcgeorge]

I've found local state to be extremely broken in 2.5. I tried always: true but can confirm that doesn't help. The @exports issue I was able to repro, but the various state not updating issues I struggled to repro, they seem to be network dependent.

[hwillson]

This issue was fixed in https://github.com/apollographql/apollo-client/pull/4586/commits/ad447951e25bd41f6e691350556c01f374447354, and will be released with apollo-client 2.6.0 shortly.

[nuragic]

Great! Looking forward to test it. Thanksss

[benjamn]

As @hwillson indicated above, this problem should be fixed if you update apollo-client to version 2.6.0-beta.2 (just released): https://codesandbox.io/s/q7n4z9zp96

We're not quite ready to release [email protected] officially, but that will happen faster if folks can help us test the beta versions. 🙏

[supercranky]

I tried out 2.6.0-beta.2 and in my use case (running a query offline) @client(always:true) is still not triggering the local resolver, it's just reading directly from the cache. Let me see if I can put together an example of this

[nuragic]

For @client only queries it's working now! Updated the sandbox (using latest beta 4).

Please feel free to add a mixed client/server example @supercranky

[supercranky]

I forked the sandbox and made an example: https://codesandbox.io/embed/5z6nvynwvl

My use case is that I need @client(always:true) fields to be resolved in offline mode but I'm guessing that they simply aren't resolved in any cache mode right now

[supercranky]

Made a new example with some cache busting (added an unused counter variable to the query)
https://codesandbox.io/s/1vx1nn7m7q

This works (even offline), so I'm guessing that there is some kind of memoization going on in either react-apollo or the apollo client

[OurMajesty]

https://codesandbox.io/s/0mov565w5v

having the same issue

[benjamn]

@supercranky Let's continue the discussion of offline refetches in https://github.com/apollographql/apollo-client/pull/4840 (warning: that change may not be safe for 2.6.0, given the current release candidate status, but could land soon afterward).

[benjamn]

Closing since we just published the final version of [email protected] to npm, including some improvements to the functionality discussed in this issue. While there may still be related issues that are worth addressing, we are happy to continue those discussions in new issues. See CHANGELOG.md if you're curious about the other changes in this release.

[OurMajesty]

The error is still reproduced with latest client
https://codesandbox.io/s/alwaystrue-0c0h0

[OurMajesty]

@benjamn 2.6.2 - same error, should I recreate issue?

[lifeiscontent]

@hwillson @benjamn can someone please follow up? I'm also experiencing issues with this.

resolvers only seem to run for preloading values in the cache and not 100% of the time.

[jim-arbete]

Still an issue.

[manjunath-satyamurthy]

seems like, it still isn't resolved !

the resolvers are only called the first time and never again.

for the time being I using a similar approach to @supercranky 's cachebust hack..

but its so ugly !

[josnin]

once its cache it will not trigger again maybe you can do a work around like change query operation name in your caller
ex.
query GetBook1 {
book
}

query GetBook2 {
book
}

[jcaguirre89]

I did what they recommended in #3315 and it worked---just adding a call to refetch somewhere in the component will forcefully run the resolver, at the cost of extra renders

[jaxxreal]

Still an issue with "apollo-client": "2.6.2"...