I m using ```graphql kotlin``` together with a webserver cal

Question

I m using ```graphql kotlin``` together with a webserver called Armeria that has support for graphql java and an example for graphql kotlin The problem is that there is no way to get the `RequestContext` in suspend functions nor to use the Dispatchers provided by Armeria in an easy way I ve solved it by extending and overriding methods in `FunctionDataFetcher` It seems that `runSuspendingFunction` has parameters for at least `CoroutineContext` so does that mean there are plans for greater configurability E g by allowing the specification of a `CoroutineContext` in the constructor of `FunctionDataFetcher ` or something similar I doubt the problem is unique to Armeria since I can t figure out how to pass the context through to suspending methods without byte code instrumenting graphql kotlin runtime

Tobias · Answer

The Armeria example <https github com line armeria tree master examples graphql kotlin>

Tobias · Answer

Just some context Since Armeria is primarily a java server `RequestContext` is available through a wrapped ThreadLocal but has extensions to invoke suspend functions turning the RequestContext into a context element

Tobias · Answer

And the Armeria bug <https github com line armeria issues 3785>

Dariusz Kuc · Answer

TLDR since we rely on `graphql java` execution logic we are constrained with what we can do with Coroutines due to the `graphql java` dependency on `CompletableFuture`

Dariusz Kuc · Answer

looks like Armeria has its own mechanism for propagating the context so you would need to create custom `FunctionDataFetcher` that incorporates that logic

Dariusz Kuc · Answer

for your use case gt probably it would be the easiest to just override `runSuspendingFunction` in your custom data fetcher so it reads stuff from armeria context

Tobias · Answer

Yup sorry I see that I missed saying that I ve already done that in my code Now the problem is doing it in a more stable way

Tobias · Answer

My question is more in the form of Can the CoroutineContext be exposed as a constructor argument in e g SimpleKotlinDataFetcherFactoryProvider and propagated to the FunctionDataFetcher and finally into `runSuspendingFunction`

Tobias · Answer

I would assume that it would be useful for more than me to replace the GlobalScope s Default Dispatcher with their own Dispatcher same with the ability to propagate webservers context

Dariusz Kuc · Answer

you can create your own factory provider that injects some context

Dariusz Kuc · Answer

underlying issue is the same gt when we switch between completable future and coroutines we break structured concurrency

Tobias · Answer

Absolutely

Dariusz Kuc · Answer

proper fix would be to rewrite the execution logic so it is coroutine aware so then you have proper parent child relationship

Joe · Answer

we did some initial work that I think relates this here <https github com ExpediaGroup graphql kotlin pull 879> but not merged due to some cases not being handled around proper parent child relationship might be useful or not

Tobias · Answer

I think there may be a misunderstanding here Armeria is not calling from a coroutine It s calling from graphql java normal vanilla code on certain Executors

Tobias · Answer

What I want is to inject my own context with a custom dispatcher using their blocking threads pool as the context everything is launched on

Tobias · Answer

and also where I can prepare some context element magic to propagate the RequestContext attribute which is a normal java class

Tobias · Answer

Which I can do fine by overriding the methods in the DataFetcher

Tobias · Answer

What I was hoping for is that the CoroutineContext variable could be set in the constructor since it seems to me like a common problem

Tobias · Answer

Let s see if I can make a PR

Dariusz Kuc · Answer

as I wrote before <https kotlinlang slack com archives CQLNT7B29 p1629743424036000 thread ts=1629741834 033900 amp cid=CQLNT7B29>

Dariusz Kuc · Answer

but that again should be a custom code and not part of SDK

Tobias · Answer

Yes but I believe the SDK could be more helpful without adding clutter I ve added a PR that you can reject without any comment if you don t like it but just so I m not being misunderstood <https github com ExpediaGroup graphql kotlin pull 1247>

Tobias · Answer

I ll shut up now smiley