Return local-only fields in subscription responses

[Narretz]

Right now, if you use @client in gql subscription response, the field is never populated.

This is probably because subscription responses aren't cached like queries, even though individual types are cached.

However, this is extremely counter intuitive. A subscription response isn't that different from a query response. InMemoryCache should populate the local only fields once after the data is received.

Otherwise it should be clearly stated in the docs that this is not possible, or apollo client should throw if a subscription gql document contains the @client directive.

[jerelmiller]

Hey @Narretz 👋

This actually seems like a bug, so I'm going to move this over to the core repo. I did a quick peek at the code path for subscriptions and it should be running local resolvers and caching data like queries do. In fact, if subscriptions didn't write to the cache, our Spotify showcase would be completely broken as it depends on this behavior.

Would you be willing to share a reproduction of the issue? This will help us dive a bit deeper to understand what might be happening. Thanks!

[Narretz]

Hi @jerelmiller thanks for taking a look. I have opened a PR that contains a test case I would expect to pass: #11281

[Narretz]

The spotify showcase isn't affected because there are no @client directives in the subscriptions I can see:
https://github.com/apollographql/spotify-showcase/blob/ce4005c8d6016b61dfa33181914acc5eba5f33ec/client/src/components/PlaybackStateSubscriber.tsx

This isn't a general problem with the cache, it's just that with subscriptions, the logic that populates @client fields isn't triggered.

[bignimbus]

Thanks a bunch @Narretz 🙏🏻 the team has been discussing this, not sure exactly when we'll be able to move this forward but we are very appreciative of the report and failing tests case ❤️

[usmansbk]

What's the status of this issue?

[jerelmiller]

I just did a bit of a deeper look into this and appears this is an issue specifically when using @client fields with read functions. Looks like this does not affect @client fields when using local resolvers.

I don't have a timeline on when we can fix this issue, but if you need a workaround for now, try using a local resolver to resolve the value of the field.