Controller method cannot return CompletableFuture if any method argument is Mono

[koenpunt]

When returning CompletableFutures from datafetchers we sometimes encounter an error in the lines of Unknown value 'java.util.concurrent.CompletableFuture@e77cd7a[Completed normally]'.
By converting the future to a mono it should be handled properly.

This is probably not a complete solution, and maybe the returned CompletableFuture should be handled somewhere different, but this at least seems to solve the issue.

[koenpunt]

Not sure if more types should be checked here? Or whether this "shortcut" of not processing the return value should be removed completely, because even when there aren't any Mono types in the arguments, the return type still could be a Publisher or CompletableFuture.

[rstoyanchev]

Generally, we mean to let CompletableFuture pass through, with no additional processing needed, since GraphQL Java anyway expects asynchronous values to be of that type. The way support Reactor types is to turn Mono into a future in ContextDataFetcherDecorator. So now with this change we would turn the future to Mono, only to turn it back to a future again before it gets to GraphQL Java, which shouldn't be necessary.

Can you provide more details on the original problem, what do you observe and what happens exactly? Is it an error log message, or an error in the response, what component creates that "Unknown value" error message, etc

[koenpunt]

Can you provide more details on the original problem, what do you observe and what happens exactly?

I can't verify it myself right now, but I believe that if you run the test without the implementation changes you should be able to observe the problem yourself.

[koenpunt]

But the issue we were experiencing was along the lines of that a resolver function with a signature like fun name(user: User): String, with a parent type like fun user(): CompleteableFuture<User> was failing on the fact that it couldn't find a method on the controller that accepted a CompleteableFuture<User>.

For all those cases we added toMono(), because a signature like fun user(): Mono<User> works allright, but I would expect that to work for CompleteableFutures as well.

[koenpunt]

I did look into it again, and I now remember what was going wrong; the returned CompleteableFuture is wrapped in a Mono when one of the parameters is a Mono (which is the case when for example there's a Principal argument defined in the resolver method).

This mono is then unwrapped somewhere, but then it's still a CompleteableFuture, and thus no matching resolver method can be found.