Hi everyone, I am running into a weird issue in re...

# apollo-kotlin

[dorche]

Hi everyone, I am running into a weird issue in regards to parsing (kinda continued from a couple message above)..
My GraphQL schema defines the queries like

type Query {
  games: [Games!]!
}

This results in a Response adapter with the following fromJson code

public override fun fromJson(reader: JsonReader, customScalarAdapters: CustomScalarAdapters): GetGamesQuery.Data {
      var _games: List<GetGamesQuery.AllAccount>? = null

      while(true) {
        when (reader.selectName(RESPONSE_NAMES)) {
          0 -> _games = Games.obj().list().fromJson(reader, customScalarAdapters)
          else -> break
        }
      }

      return GetGamesQuery.Data(
        games = _games!!
      )
    }

But when my server encounters a “GraphQL” when running this query, the response that it sends down fails to parse, details in 🧵

[dorche]

Server response has the structure of

{
  "errors": [
    {
      "message": "some-message-string",
      "extensions": {
        "type": "important_error_type_business_logic"
      }
    }
  ],
  "data": {}
}

Which then fails the parsing, I assume because of that force unwrap in the Adapter

[dorche]

if I intercept the server response and change it to

{
  "errors": [
    {
      "message": "some-message-string",
      "extensions": {
        "type": "important_error_type_business_logic"
      }
    }
  ],
  "data": {
    "games": []
  }
}

Parsing works as expected.

Is this a bug on the server side? Is there anyway I could get around it on the Kotlin side?

[bod]

Hi!
In GraphQL there's the notion of errors "bubbling up" which means that if a field is marked non nullable (such as games in your case), if it can't be resolved due to an error, then the whole object containing it will be null, if that's not possible because it's itself non nullable, then its parent will, and so on, recursively, until we reach data which is nullable.

In your case, games is not nullable, so "data": {} is invalid. Its parent, data , should be null instead.

[bod]

Here's a good article about nullability in GraphQL: https://www.apollographql.com/blog/graphql/basics/using-nullability-in-graphql/

[dorche]

Thanks for the quick response!

So do I need to tell the server engineers that they should instead return

{
  "errors": [
    {
      "message": "some-message-string",
      "extensions": {
        "type": "important_error_type_business_logic"
      }
    }
  ],
  "data": null
}

in such cases?

[bod]

correct ✅

[bod]

in fact, no "data" at all should also work