Search code examples
graphqlaws-appsync

GraphQL error FieldsConflict: fields have different list shapes


I'm using AWS AppSync's GraphQL server with the following (simplified) schema:

type Query {
  getIssue(id: String!): Issue
}

type Issue {
  id: String!
  data: IssueData!
}

type Event {
  id: String!
  time: AWSDateTime!
  status: [String]
}

type Payment {
  id: String!
  amount: Int!
  status: String
}

union IssueData = Event | Payment

When I make a query that includes inline fragments to select the status as a child of either an Event or Payment type in the Issue/data field, I get a FieldsConflict error:

query getIssue($id: String!) {
  getIssue(id: $id) {
    id
    data {
      ... on Event {
        time
        status
      }
      ... on Payment {
        amount
        status
      }
    }
  }
}

Validation error of type FieldsConflict: status: fields have different list shapes @ 'getIssue/data'

This is presumably caused by the Event/status field returning an array of strings, while the Payment/status field returns a single string.

Why does GraphQL consider this to be a conflict? How should I construct my query to allow access to the status field on both data types?

Note that I'm using a union rather than an extended interface because the Issue and Payment types have no common data structure.


Solution

  • From the spec:

    If multiple field selections with the same response names are encountered during execution, the field and arguments to execute and the resulting value should be unambiguous. Therefore any two field selections which might both be encountered for the same object are only valid if they are equivalent.

    You can resolve the issue by providing a field alias for one or both fields:

    query getIssue($id: String!) {
      getIssue(id: $id) {
        id
        data {
          ... on Event {
            time
            eventStatus: status
          }
          ... on Payment {
            amount
            status
          }
        }
      }
    }
    

    Renaming one or both fields in your schema would obviously also resolve the issue.