Inconsistent results when using fragments

I am finding that the order of data in the query really matters.

//query
const query = graphql`
    query EntryQuery($id: Float) {
      queryEntry(filter: { id: { eq: $id } }) {
        ...EntryBanner_entry
        images {
          source
        }
      }
    }
    ${EntryBannerFragment}
  `;

const fragment = graphql`
  fragment EntryBanner_entry on Entry {
    title
    images {
      source
      type
    }
  }
`;

This will output the correct object:

{
  title: string
  images: { source: string, type: string }[]
}

However if I change the order of the data and fragment:

const query = graphql`
    query EntryQuery($id: Float) {
      queryEntry(filter: { id: { eq: $id } }) {
        images {
          source
        }
        ...EntryBanner_entry
      }
    }
    ${EntryBannerFragment}
  `;

Then the object is:

{
  title: string
  images: { source: string }[]
}

Why is this the case?

Can you make sure that it is the same in general GraphQL Specs? For example, run an Apollo GraphQL server and test it. If it has the same behavior, it is part of GraphQL Spec and you may found why in their docs. If no, we can consider it as a Bug in Dgraph.

Cheers.

I have tested this using a simple Apollo and Hasura Server. The placement of the fragment didn’t matter, it always respected the data requested so this is a bug in Dgraph.

Your query and the fragment are both querying for images { ... }. Is that what you’re expecting? The behavior you’re reporting shows that the query is picking up the first occurrence. Dgraph needs to end up choosing one of the queries on the same field to return.

That is correct. When I tested on Apollo and Hasura both returned back the data I was asking for, no matter the order or how it was broken up in fragments. I’m assuming it is a bug if Dgraph is just choosing one occurrence and ignoring the rest since this isn’t how it is handled on Apollo or Hasura.

2 Likes

Hi! I don’t think Dgraph has the right behaviour here! According to the GraphQL specs, Field Collection should be possible. This non-compliance of Dgraph is actually quite a problem for people using Relay since they sometimes rely on multiple Fragments if they consider using the useFragment hook.

Any updates on getting this fixed @dmai? I did some tests today and it is still a problem.

1 Like

Hey @charklewis!

I guess the entire problem is connected to @graphql-codegen. I’m not sure but I think I found the part where field collection according to the GraphQL specs was implemented in the source. Something similar should be possible with the Fragment Matcher plugin but maybe this can only be used with Apollo?

Is there any news from your end since you were saying that you are working on this?

Cheers!

This issue should be solved by the newest update

v21.03.0-92-g0c9f60156

2 Likes

Do you know when this makes it to Dgraph Cloud?

I have tested it today and it works for me. Maybe they have not updated all endpoints yet?

I might be wrong but I guess they have different backends? I received the information that they have rolled out the update on

https://empty-tree.us-east-1.aws.cloud.dgraph.io/graphql