Is wrapping data fetcher calls in virtual threads useful when spring boot already uses virtual threads?

[ptorkko]

I made a really stupid mistake and spent way too long on resolving it: call .join() on a future from a batched data loader in a data fetcher

This causes the graphql-java execution model to get stuck, with no timeouts or anything set up out of the box and nothing progressing without explicit calls to the loaders dispatch method.

So this got me thinking, does defaulting to virtual threads in DGS if spring boot is already using them do anything useful in most cases?

@DgsQuery
public DataFetcherResult<List<Author>> authors(...) {
  /* this runs on a tomcat virtual thread already */
}

@DgsData(parentType = DgsConstants.AUTHOR.TYPE_NAME)
public CompletableFuture<List<Book>> books(DgsDataFetchingEnvironment dfe) {
  var booksLoader = /* a mapped batch loader */
  return booksLoader.load(dfe.getSource().getKey(), dfe.getLocalContext());
  // .join() here would block the graphql-java execution if there are >1 keys
}

Calling .join() and not returning a future from the data fetcher using a loader is an obvious mistake in hindsight, but with virtual threads the way this blocks is really confusing as thread dumps show nothing special (and you basically need to use jcmd to even see the virtual threads states).

Not sure there is anything the framework can do to detect this at runtime, so in our case we should set up static analysis to complain that not returning a future when using data loaders probably means something is wrong.

It's very possible I'm missing some obvious benefit, so interested to hear.