I have a question regarding nullable items, specif...

# graphql-kotlin

[Martin Brehovsky]

I have a question regarding nullable items, specifically interested in functions which return completable futures. At this point it seems every time a given function returns a nullable value (or nullable type of CF), when the dependency fails, the query returns null and then details in the error field in the response. Failures for the non-nullable types fail the whole query.

I guess this works for most of the cases, but what if I need to fail the query completely in the case it given function return a nullable object? Pretty much need to differentiate between a regular value (which can be nullable) and the actual failure -> fail the whole query and not return null). Is something like this doable?

[Dariusz Kuc]

If there is a critical failure then just throw exception

[Dariusz Kuc]

If you need to return partial data then return data fetcher result with both data and exception

[Martin Brehovsky]

Is it possible to specify this behavior in the CF itself? Or do I need to write a custom DataFetcher?

[Dariusz Kuc]

why do you need to work with completable future?

[Dariusz Kuc]

*and yes you should be able to throw exceptions from CF

[Martin Brehovsky]

I'm using DataLoaders to load most of the data to the graph. I created a couple of helpers which allow me to easily bridge those from Reactor's Mono streams (using SpringBoot/Webflux as the base framework - historical reasons).

[Martin Brehovsky]

However when I return a failed CF, the query returns null and the error is in the error section. Would like to fail the whole query in such a case.

[Dariusz Kuc]

apologies but still not sure what you are trying to do

[Martin Brehovsky]

E.g.

fun failNullableCF(): CompletableFuture<Boolean?> = CompletableFuture.failedFuture(RuntimeException("failed nullable future"))
    fun failNonNullableCF(): CompletableFuture<Boolean> = CompletableFuture.failedFuture(RuntimeException("failed non nullable future"))

failNullableCF ends up with

{
  "data": {
    "dog": {
      "failNullableCF": null
    }
  },
  "errors": [
    {
      "message": "failed nullable future",
      "locations": [
        {
          "line": 3,
          "column": 5
        }
      ],
      "path": [
        "dog",
        "failNullableCF"
      ]
    }
  ]
}

[Martin Brehovsky]

I would expect this failure to fail the whole response.

[Martin Brehovsky]

Like this:

{
  "errors": [
    {
      "message": "failed non nullable future",
      "locations": [
        {
          "line": 3,
          "column": 5
        }
      ],
      "path": [
        "dog",
        "failNonNullableCF"
      ]
    }
  ]
}

[Martin Brehovsky]

(the first query is

{ 
  dog {
    failNullableCF
  }
}

and the second query is

{ 
  dog {
    failNonNullableCF
  }
}

[Dariusz Kuc]

if you attempt to return a null value for a non-nullable field -> it is considered a critical failure so it will bubble up until the top field (hence just the errros block)

[Martin Brehovsky]

Right, however semantically a failed CF is not null

[Dariusz Kuc]

in case of a nullable field -> null is a valid value and GraphQL supports partial data

[Martin Brehovsky]

it is a CF completed exceptionally

[Dariusz Kuc]

you would have to dig into the graphql-java logic to see how it resolves the CF failures

[Dariusz Kuc]

sounds like it sees no value => defaults to null and adds the exception from CF failure so treats it as a partial

[Martin Brehovsky]

BTW I can see a similar behavior in this case though:

fun failNullableFun(): Boolean? = throw RuntimeException("failed nullable function")
    fun failNonNullableFun(): Boolean = throw RuntimeException("failed non nullable function")

{ 
  dog {
    failNullableFun
  }
}

returns as

{
  "data": {
    "dog": {
      "failNullableFun": null
    }
  },
  "errors": [
    {
      "message": "failed nullable function",
      "locations": [
        {
          "line": 3,
          "column": 5
        }
      ],
      "path": [
        "dog",
        "failNullableFun"
      ]
    }
  ]
}

I would expect the query to completely fail

[Dariusz Kuc]

well each field is resolved independently

[Dariusz Kuc]

so dog was resolved

[Dariusz Kuc]

but subsequent field failed (but since it is nullable) it is fine

[Dariusz Kuc]

if you want to fail whole query you would need to resolve complete object in the top level query (i.e. in dog)

[Martin Brehovsky]

right - what you say makes sense to some extent, but semantically failNullableFun failed, it did not resolve

[Dariusz Kuc]

graphql supports partial data

[Martin Brehovsky]

in other words - there is no difference between

fun failNullableFun(): Boolean? = throw RuntimeException("failed nullable function")

and

fun nullableFun(): Boolean? = null

when resolving the actual values.

[Dariusz Kuc]

well there is a diff -> in first case you will get errors populated

[Martin Brehovsky]

True there is a diff, however this makes client's life more difficult as they will need to check if there is an error in the case they got null for a value

[Martin Brehovsky]

hence going back to my original question - is it possible to fail the whole query in the case given node is nullable and we fail when obtaining its value

[Dariusz Kuc]

you can take a look at the DataFetcherExceptionHandler that is provided to the execution strategies

[Dariusz Kuc]

this is the default https://github.com/graphql-java/graphql-java/blob/master/src/main/java/graphql/execution/SimpleDataFetcherExceptionHandler.java

[Dariusz Kuc]

unsure though why you would want to change this behavior

[Martin Brehovsky]

Thanks for the pointers. As I wrote, when we fail obtaining a nullable field, it should be still considered as a failure as there is a difference between null as a properly loaded value and a failure.

One could argue if we care a lot about preserving null as a valid value we should use a wrapper, something like Optional to express this semantic, and I agree this would be perhaps the best approach. However since GraphQL does not support generic types, this would require creating a union type for each combination, and that does not scale well.

Pretty much exploring what other options we have and what would be the best pattern to use to support cases when we can partially fail vs we need completely fail.

[Martin Brehovsky]

Anyway thanks for all the pointers here, will explore more 🙂

[Shane Myrick]

I think you may need to wrap the result here and have logic to handle the errors of the completable future

CompletableFuture<DatafetcherResult<T>>

[Martin Brehovsky]

Thanks, will try something out