Fragments stopped working after graphql update

[asmodeoux]

Describe the issue
I updated graphql package from 3.1.0 to 4.0.1 and now GraphQL responses with fragments are not operated correctly. Here is an example on StackOverflow: https://stackoverflow.com/questions/70393062/json-fails-to-parse-graphql-response-after-flutter-libs-upgrade

I'm not sure if it's related directly to graphql update or is there something wrong with parsing the response with json libraries, but I hope anyone here knows what's going wrong. I checked all the changelogs and docs and didn't find any info about that.

To Reproduce
Steps to reproduce the behavior:

1. Update graphql from 3.1.0 to 4.0.1
2. Make a fresh build after flutter clean & updating the pods

Expected behavior
Old documents are working correctly and everything works as well as on 3.1.0

Actual behavior
Documents with fragments don't parse correctly anymore

device / execution context
iOS 14/15, also reproducible in Android

additional context
All the additional context is available in my StackOverflow post, please check it for code samples and screenshots

additional notes
I like everything but I hope it will work for me again :-)

[vincenzopalazzo]

I checked all the changelogs and docs and didn't find any info about that.

Maybe because the version that you are using it is the only one, there is a beta version available here https://pub.dev/packages/graphql/versions/5.0.1-beta.1 can you check with it?

[asmodeoux]

@vincenzopalazzo I've just checked and 5.0.1-beta.1 also doesn't work, same behaviour

[vincenzopalazzo]

Mh, interesting. Any tips to reproduce the error in a local env?

Thanks

[asmodeoux]

@vincenzopalazzo unfortunately the API I use is private and pretty hard to reproduce since there's authorisation needed. If there's any API you know where you can use fragments in queries you can try that.

[vincenzopalazzo]

Some app example contains fragments but I need to update them. I will put in my to-do list, but not sure that we can reproduce your error with another API. But we will see

[alitnk]

I am also getting null when I use fragments.

Edit: mine turned out to be fixed with fetchPolicy: FetchPolicy.noCache (#950)

[vincenzopalazzo]

@alitnk

Can you provide an small example? maybe we have a bug somewhere?

[alitnk]

@vincenzopalazzo
This is the repository in which I'm facing the issue: https://github.com/matnbaz/matnbaz-mobile
You could look for FetchPolicy.noCache occurrences and try to remove them.
Let me know if this example has too much unrelated code or is just isn't good for testing the problem, I'd gladly make a small example.

And thank you for your time. the library is working perfectly, except for this issue.

[asmodeoux]

@alitnk Thanks, this noCache workaround helped me as well

[vincenzopalazzo]

Let me know if this example has too much unrelated code or is just isn't good for testing the problem, I'd gladly make a small example.

If you can provide a small example will be perfect to me, and we can try to accelerate the debugging of it :) thanks

[alitnk]

If you can provide a small example will be perfect to me, and we can try to accelerate the debugging of it :) thanks

There you go: https://github.com/alitnk/graphql_flutter_fragments_example

Worth mentioning that I'm using Artemis in this example, So the query document is auto generated.
Please mention me if there's an issue with the example repo.

[vincenzopalazzo]

Amazin, I will prioritize this issue in my queue to prove my gratitude to build this example.

Thanks!

[micimize]

The newer cache uses __typename to intelligently deconstruct and reconstruct the data using the normalize library, but it shouldn't try and do anything fancy without it.

1. Add __typename such as is supplied by the gql` helper
2. Try supplying possibleTypes to the cache (i.e. {"Role": {"Client"}})
3. See if normalize is 0.5.5. This issue maybe caused by some issue with fragments resolved in 0.5.5 (https://pub.dev/packages/normalize/changelog):
   

   graphql-flutter/packages/graphql/pubspec.yaml

   Line 16 in f0793fd

   normalize: ^0.5.3

Ultimately the cache shouldn't do anything to query objects without __typename available to work with or customizations

[budde377]

@vincenzopalazzo, I've worked on improving how normalize parses fragments (see latest gql-dart/ferry#300). As @micimize suggests, I expect this issue to be caused by this. In the coming versions of normalize, users will need to supply possibleTypes to the client. We'll need to update the documentation to reflect this. I'm using graphql_codegen to generate these types myself.

[budde377]

@asmodeoux Please try the following:

• Add the normalize dependency to version 0.5.3, exactly.
• Add __typename to all your query objects
• Provide possibleTypes map. You can generate this with GraphQL codegen (https://pub.dev/packages/graphql_codegen)

[msal4]

I'm facing the same issue I didnt have it before 5.0. possibleTypes is null for all my types. the noCache workaround seems to work but i'd prefer to keep the cache. I'm using artemis btw
I'd appreciate any guidance. Thanks for all your hard work :)

[vincenzopalazzo]

Hi @msal4,

another solution can be to fix the version normalize: 0.5.3, with dependeces override as suggested here

Add the normalize dependency to version 0.5.3, exactly.

We are working on a solution because normalize as a breaking change in the last version, so we are deciding if we need to work with an old solution or we need to update the doc to support the new one.

Sorry for that

[msal4]

Hey @vincenzopalazzo, I've already added normalize: 0.5.3, still facing the same issue.

[budde377]

I'm planning on working on this this weekend. Btw,Artemis has their own client, right? So this would be the wrong repo?

[msal4]

@budde377 great!
yeah i know. I only use artemis for codegen I dont use their client. plus graphql_flutter works better with flutter.

[budde377]

I've created a PR outlining the steps necessary to get proper fragment resolution with the new version of normalize.

@alitnk Regarding your example, as far as I can see you're not providing the possibleTypes (here: https://github.com/alitnk/graphql_flutter_fragments_example/blob/master/lib/main.dart#L17) or introspection upon fragment spread (e.g. here https://github.com/alitnk/graphql_flutter_fragments_example/blob/master/graphql/queries/get-repositories.graphql#L21).

@msal4 Please check the documentation to see if it makes sense.

[vincenzopalazzo]

The new release is out https://github.com/zino-hofmann/graphql-flutter/releases/tag/v5.0.1-beta.3

[msal4]

@budde377 hey, sorry for the late response. I tried doing what you mentioned but still i couldn't get it to work unless i disable cache. I dont have any interfaces defined in my graphql schema and I already have __typename in my queries. I'm quite confused tbh.

[budde377]

@msal4, can you provide a reproducible example of this?

A repo with your queries, schema, pubspec, and how you're using the client.

[msal4]

@budde377 Apparently artemis generator doesn't seem to be working with graphql-flutter anymore, haven't checked why exactly but it's something related to the generated queries. I switched to graphql_codegen and everything seems to work just fine.
thanks :)

[geiszla]

We have a problem with interface fragments that might also be related to this issue.

We have an interface for the user fields called UserInterface, and a type called Self, which is derived from the UserInterface. When we define the fragment as fragment UserFields on UserInterface and spread it in another fragment as fragment SelfFields on Self { ...UserFields }, on web (using Apollo client) it can correctly return the fields from both the user and self types. On mobile it correctly spreads the fragments and the server returns the fields (can be seen on the response object in devtools network tab), but graphql_flutter doesn't return it on the result object. It probably doesn't realize that the UserInterface fields should also be on the object with type Self.

Any ideas on how to solve this?

[budde377]

As mentioned earlier in this thread, please try and update graphql flutter to the latest version (possibly beta), add __typename if it's not already provided by your query transformer, and supply a possibleTypes map to the client