Fragments of concrete types when querying interface fields throwing an error

[davidyaha]

I am getting an error while querying with a fragment of certain type in a field that is defined as interface:

  fragment message on Message {
      _id
      text
      createdAt
      user {
        _id
        avatar
      }
      reply {
        __typename
        expiration
        ... on OptionsReply {
          options
        }
      }
    }

The query being:

query chat($offset: Int!, $limit: Int!) {
    user: me {
      _id
      avatar
    }
    messages(offset: $offset, limit: $limit) {
      ...message
    }
  }

The error I am getting is the following "Network error: Can't find field options on result object $ROOT_QUERY.messages({"offset":0,"limit":50}).0.reply."

After poking the client code I found this error is being thrown here: https://github.com/apollostack/apollo-client/blob/master/src/data/writeToStore.ts#L184

It is supposed to be thrown when you don’t get a field that is in the selection fields. I think that the graphql spec defines fragments as a way to get fields of interfaces when they are implemented on a concrete type.

It seems that the client does check for the fragment type here: https://github.com/apollostack/apollo-client/blob/master/src/data/writeToStore.ts#L246
but it does not compare it to anything AFAIK.

Is this a bug? if so is there a fix on the way? if not, do you think a simple check on the line I pointed out could get rid of this error?

Thanks ahead!

[davidyaha]

Wrote a failing test:

    it('should resolve fields it can on interface with non matching inline fragments', () => {
      storeRoundtrip(gql`
        query {
          dark_forces {
            __typename
            name
            ... on Droid {
              model
            }
          }
        }`, {
        dark_forces: [
          {
            __typename: 'Droid',
            name: '8t88',
            model: '88',
          },
          {
            __typename: 'Darth',
            name: 'Anakin Skywalker',
          },
        ],
      });
    });

Will try to fix it later today but it made me realise a workaround for it.
For anyone that comes across this issue before a fix is deployed, just make sure all possible concrete types have their own fragment in the query.

for the test above, the following query will not throw an error and give the same results:

query {
  dark_forces {
    __typename
    ... on Droid {
      name
      model
    }
    ... on Darth {
      name
    }
  }
}`