Feature Request - default CoroutineContext

[pkozakCC]

Discussed in #36738

^{Originally posted by pkozakCC October 27, 2023}
There are cases where the default CoroutineContext has to be modified for all suspendable RestEasy Resource method calls, for example in order to add a custom CoroutineContext.Element for every request, that would hold application-specific details, such as tenant ID (which is precisely my case btw).

This can be done manually, but it's tedious and error-prone.

It would be nice to introduce a mechanism that would make it possible to modify the default CoroutineContext.
It can be either of a form CoroutineWebFilter, that would return a suspendable function and would respect the context in the downstream, e.g.:

    suspend fun filter(
        serverWebExchange: ServerWebExchange,
        webFilterChain: CoroutineWebFilterChain,
    ): Mono<Void> {
        return withContext(MyCustomCoroutineContextElement()) {
            webFilterChain.filter(serverWebExchange)
        }
    }

    interface CoroutineWebFilterChain {
        suspend fun filter(serverWebExchange: ServerWebExchange): Mono<Void>
    }

Or similarly to the Spring approach (links below) - registering a list of CoroutineContext.Element in a filter (per request)

After:

• https://stackoverflow.com/questions/77370339/quarkus-default-coroutines-context?noredirect=1#comment136401015_77370339

Spring Webflux approach for the issue (which will be released in 6.1) - current implementation of CoWebFilter does not respect the CoroutineContext changes:

• Propagate CoroutineContext in CoWebFilter spring-projects/spring-framework#27522
• spring-projects/spring-framework@b0aa004

[quarkus-bot]

/cc @evanchooly (kotlin), @geoand (kotlin)

[geoand]

Do you have some example of what exactly you are trying to do?
I am asking because I would like to get a sense of what problem we are trying to solve here.

Thanks

[mschorsch]

The author would like to have a possibility to modify the CoroutineContext before calling the resteasy reactive endpoint, with the aim of storing additional data in the CoroutineContext. This data would then be automatically available via the CoroutineContext in all suspendable resteasy reactive endpoints. The advantage of the CoroutineContext is that it is automatically propagated by the Kotlin coroutines and therefore no longer needs to be managed by the user. A typical use case is the use of the MDC (https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-slf4j/kotlinx.coroutines.slf4j/-m-d-c-context/). In this case, the author probably wants to pass the tenantId for all resteasy reactive resources.

+1

[geoand]

The author would like to have a possibility to modify the CoroutineContext before calling the resteasy reactive endpoint, with the aim of storing additional data in the CoroutineContex

Yeah, I get that. What I want to see is some pseudo-example of what this would be used for

[cogman]

@geoand here's what I'd like to do.

@GET
suspend fun getIt(id: Int): It {
  MDC.put("get.id", id)
  return withContext(Dispatcher.IO) {
    dao.getIt(id)
  }
}

With a default coroutine context (or something like it). I could set it up as

  fun defaultSetup(rootContext: Context): Context {
    return rootContext.plus(MDCContext())
  }

This would propagate MDC values through coroutine calls (which is what I want to do).

In order to do this as of now, I have to do something like this on every endpoint

  fun getIt(id: Int): It = withContext(MDCContext()) {
    return@withContext etc()
  }

[geoand]

Thanks for the update!

[geoand]

@cogman I think I have an idea of how to make this work, but what would be super helpful in testing it would be if you could attach a sample application where you are using the feature you mention above.

Thanks

[geoand]

@cogman ^