Cannot return null for non-nullable field when throwing error

[Cretezy]

Apollo Gateway: 0.33.0

Apollo Federation: 0.26.0

Apollo Server: 3.0.1

---

I have a federated graph, with a service with the following schema:

# Service A
type User {
  id: ID!
}

type Query {
  me: User!
}

# Service B
type Query {
  permissions: [String!]!
}

In my resolver, it's defined roughly like:

// Service A
me: async (_, __, ctx) => {
  // from `context`
  if(!ctx.user) {
    throw new AuthenticationError("MISSING_AUTHENTICATION")
  }

  return getUser(ctx.user);
}

// Service B
permissions: async (_, __, ctx) => {
  // from `context`
  if(!ctx.user) {
    throw new AuthenticationError("MISSING_AUTHENTICATION")
  }

  return getUserPermissions(ctx.user);
}

With the following query:

{
  me {
    id
  }
  permissions
}

Actual

When querying me without ctx.user set, it returns 2 errors instead of 1.

Errors:

Error: MISSING_AUTHENTICATION

Cannot return null for non-nullable field Query.permissions.

Expected

I believe it should only return a different error.

Errors:

Error: MISSING_AUTHENTICATION

Error: MISSING_AUTHENTICATION

[cactusblew]

type User {
id: ID
}

make Id nullable. that should return just the error that you are expecting

[cactusblew]

type User {
id: ID
}

make Id nullable. that should return just the error that you are expecting

Sorry, did not notice the issue was on Query.permissions. Are you sure that permissions results in a valid response. Looks like it yields in a null and hence is complaining about the schema being not optional

[Cretezy]

@cactusblew That seems to be correct, but in this case, it's returning null because the other part of the query is erroring. It seems weird that errors aren't propagated correctly here, as the error is causing another error (when it should only be returning the original error)

[glasser]

me and permissions fields are siblings of each other so GraphQL evaluates them in parallel and they can have errors separately.

If you expect permissions to only work if auth is set, then its own resolver should check the condition itself, or perhaps you could move permissions to be a field on User that you fetch via me.

After all, if you ran the query { permissions } without me and permissions didn't do its own MISSING_AUTHENTICATION check, where would the appropriate error come from?

[Cretezy]

@glasser This is not the behavior that's being described here.

me and permissions throw without authentication. In this case, both are throwing errors, however one is throwing that the authentication is missing (which is correct), and the other is saying it's non-nullable (which is incorrect, since it threw the same error).

I've updated the OP to clarify this. This still seems to be a bug.

[glasser]

Well, I didn't see your code, so I didn't know that. If you'd like us to look more into it, we need to see the whole code: something we can git clone or on codesandbox.io, say.

[Cretezy]

@glasser I will provide an example tomorrow!

[Cretezy]

Been trying to replicate for a while with no luck. Somehow no longer getting the error in the application (had found a workaround I think) too. If I can find a way to reproduce it again, I should be able to translate it to my Codesandbox. Thanks!

[glasser]

I think the issue you're talking about is the one I describe at apollographql/federation#159 (comment)

[Cretezy]

@glasser Yes that seems similar to what was my issue!

[paulpdaniels]

@glasser This broke our frontend as well, we now have two errors which are getting shown. One is meaningful but the second is always "cannot return null for a non-nullable field". Is a new issue needed? I can attempt a fix