Unexpected behavior with GraphQL arrays

Help
1

Consider the following GraphQL schema:

type Session {
  participants: [SessionParticipants]
}

type SessionParticipants @embedded {
  id: ID!
  name: String!
}

Fauna automatically generates a createSession mutation, so I can create a session like so (note the empty participants array):

mutation {
  createSession(data: { participants: [] }) {
    _id
    participants {
      id
      name
    }
  }
}

This yields the result:

{
  "data": {
    "createSession": {
      "_id": "274296545935884812",
      "participants": []
    }
  }
}

But if I inspect the document (via Fauna UI), the participants entry is not there, I would expect it to have an empty array.

{
  "ref": Ref(Collection("Session"), "274296545935884812"),
  "ts": 1597848420956000,
  "data": {}
}

This behavior is inconsistent and forces me to handle a null participants entry in any FQL function that needs to work with the array, where I prefer to initialize with an empty array.

2

I can see how this is not what you would expect and also feel this is inconsistent. I’ll ticket it.

2 Likes
3

Found another side effect that’s probably related to this.

When the array is not-nullable:

type Session {
  participants: [SessionParticipants]!
}

A mutation with an empty array…

mutation {
  createSession(data: { participants: [] }) {
    _id
  }
}

will yield:

"Field 'participants' is required and cannot be 'null'."

Can you link the issue or tell if there are any updates on this @databrecht ?

4

No updates yet if I’m not mistaking but I’ve been away on vacation, so I might be wrong. Ticket number is: PROD-807. This is only useful to communicate to other fauns about the problem. We don’t have public access to internal tickets atm.

5

Hi! Has this been solved?
I am experiencing a similar issue when trying to assign null to a field of [String!] type in hope of removing it. When I am inspecting the document in the “Collections” pane, it looks like I am getting what I want. Still, graphql returns an empty array instead when queried.
It seems like a very inconsistent behavior.