Kotlin Coroutines client impl: unable to use RequestScoped in Spring Boot due to "final" stub implementation

[dave-carbon]

We are using grpc-kotlin to generate client code in DGS, which is built on Spring Boot.

Currently we inject gRPC clients throughout our codebase with a typical Spring Boot singleton bean:

@Bean
fun someService(): SomeServiceCoroutineStub = SomeServiceCoroutineStub(...)

class Resolver(
  @Autowired private val client: SomeServiceCoroutineStub
) {
  fun field() {
    client.method()
  }
}

However we'd like to make it easy to pipe request-specific HTTP headers into our gRPC client Metadata. One obvious way to do this is with @RequestScope and javax.inject.Providers:

@RequestScope
@Bean
fun someService(): SomeServiceCoroutineStub = SomeServiceCoroutineStub(...).withInterceptors(request, stuff, here)

class Resolver(
  @Autowired private val client: Provider<SomeServiceCoroutineStub>
) {
  fun field() {
    client.get().method(...)
  }
}

Unfortunately that approach fails with the error:

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'client' defined in BeanDefinition defined in class path resource [.../Resolver.class]: Initialization of bean failed; nested exception is org.springframework.aop.framework.AopConfigException: Could not generate CGLIB subclass of class ...SomeServiceGrpcKt$SomeServiceCoroutineStub: Common causes of this problem include using a final class or a non-visible class; nested exception is java.lang.IllegalArgumentException: Cannot subclass final class ...SomeServiceGrpcKt$SomeServiceCoroutineStub

Caused by: java.lang.IllegalArgumentException: Cannot subclass final class ...SomeServiceGrpcKt$SomeServiceCoroutineStub

It looks like Spring Boot needs to be able to create a subclass to support @RequestScope, but since grpc-kotlin generates SomeServiceCoroutineStub as a final class it's failing.

---

I looked through the docs, but didn't find any way to customize the generated code. Would you be open to dropping final from the generated code to support a use-case like this?

[dave-carbon]

Alternatively: I think it would also work to codegen an interface alongside the class with all the same methods. Something like:

interface SomeServiceCoroutineClient {
  suspend fun method(...): ...
}

final class SomeServiceCoroutineStub implements SomeServiceCoroutineClient {
  ...
}

Then I believe I could @Scoped("request", ScopedProxyMode.INTERFACES) and inject like:

@RequestScope
@Bean
fun someService(): SomeServiceCoroutineStub = SomeServiceCoroutineStub(...).withInterceptors(request, stuff, here)

class Resolver(
  @Autowired private val client: Provider<SomeServiceCoroutineClient>
) {
  fun field() {
    client.get().method(...)
  }
}

[lowasser]

Is there any chance you can patch the code gen yourself and verify that this actually works? For example, I'd hate to do this and discover that e.g. Spring gets confused by the coroutines.

[lowasser]

Also we'd need to be very careful about the exposed API to subclasses; this may commit us to more constraints about the design than we want.

[dave-carbon]

Fair question! Definitely understood wanting to keep the API surface area small. This is also my first time working on a Spring project, so I'm learning too.

I haven't patched grpc-kotlin, but I did run a few sanity checks. None of these fully work, but I believe this is one of the causes of the two blockers I'm seeing.

Given the resolver:

class MyResolver(@Autowired private val myUtil: Provider<MyUtil>) {
  suspend fun someFIeld: SomeResponse {
     myUtil.get().sayHello()
  }
}

I tried a few different combinations of Scopes and MyUtil definitions. All tests used the same sayHellow() impl:

    suspend fun sayHello() {
        delay(1)
        println("Hello from my util: " + toString())
    }

Singleton scope, closed util:

@Bean
fun myUtil(): MyUtil = MyUtil()

class MyUtil {
    suspend fun sayHello() { ... }
}

This fully works, but is not scoped to a request because Spring uses singletons. I sent two requests, and both print Hello from my util: com.carbonhealth...MyUtil@7d00afcd.

---

Adding RequestScoped with a closed util reproduces what I see from grpc-kotlin:

@RequestScope
@Bean
fun myUtil(): MyUtil = MyUtil()

class MyUtil {
    suspend fun sayHello() { ... }
}

Throws error: Caused by: java.lang.IllegalArgumentException: Cannot subclass final class com.carbonhealth.graphql.identity.MyUtil

---

When I open the util, the error changes to one which looks like more of a Spring config issue on my end:

@RequestScope
@Bean
fun myUtil(): MyUtil = MyUtil()

open class MyUtil {
    suspend fun sayHello() { ... }
}

Throws error: java.lang.IllegalStateException: No Scope registered for scope name 'request'

---

I can get that same error with ProxyScope = interfaces and the "interface + closed impl" setup below

@Scope("request", proxyMode = ScopedProxyMode.INTERFACES)
@Bean
fun myUtil(): MyUtilInterface = MyUtil()

interface MyUtilInterface {
    suspend fun sayHello()
}

class MyUtil: MyUtilInterface {
    override suspend fun sayHello() {
        delay(1)
        println("Hello from my util: " + toString())
    }
}

class MyResolver(@Autowired private val myUtil: Provider<MyUtilInterface>) {
  suspend fun someFIeld: SomeResponse {
     myUtil.get().sayHello()
  }
}

Throws error: java.lang.IllegalStateException: No Scope registered for scope name 'request'

---

My current belief is that things will work if I:

1. Get an interface or non-final impl from grpc-kotlin.
2. Figure out how to configure Spring so that @RequestScoped works.

To be honest I didn't expect such a quick reply 😁. I opened this thinking "let's see if the maintainers here are open to the idea before I spend too much more time digging here..."

[dave-carbon]

Had a followup idea... so I re-ran those experiments using the built-in "prototype" scope to bypass w/e issue I'm having with request scope configs. "prototype" is Spring's scope for "new instance every time."

With the same sayHello() impl and Provider<MyUtil> argument injected into the Resolver, I tried

@Scope("prototype", proxyMode = ScopedProxyMode.TARGET_CLASS)
@Bean
fun myUtil(): MyUtil = MyUtil()

class MyUtil {
    suspend fun sayHello() { ... }
}

Throws error: Caused by: java.lang.IllegalArgumentException: Cannot subclass final class com.carbonhealth.graphql.identity.MyUtil (same as I see from grpc-kotlin)

---

open class with "subclass" strategy for proxies:

@Scope("prototype", proxyMode = ScopedProxyMode.TARGET_CLASS)
@Bean
fun myUtil(): MyUtil = MyUtil()

open class MyUtil {
    suspend fun sayHello() { ... }
}

This fully works. The two requests print:

Hello from my util: com.carbonhealth....MyUtil@4818c878
Hello from my util: com.carbonhealth....MyUtil@56b10bea

---

closed class w/ interface and "interfaces" strategy for proxies:

@Scope("prototype", proxyMode = ScopedProxyMode.INTERFACES)
@Bean
fun myUtil(): MyUtilInterface = MyUtil()

interface MyUtilInterface {
    suspend fun sayHello()
}

class MyUtil: MyUtilInterface {
    override suspend fun sayHello() {
        delay(1)
        println("Hello from my util: " + toString())
    }
}

This one also fully works. Different requests print different memory hashes.

[dave-carbon]

Been mulling this over a bit, too:

Also we'd need to be very careful about the exposed API to subclasses; this may commit us to more constraints about the design than we want.

If we went the interface route, we could have the codegen define default methods. This wouldn't affect the lib's behavior at all, since the codegen'd impl can override those to keep doing what it's doing, but would also help shield the library from users who manual users who defined other impls of their own manually for some reason.

[dave-carbon]

Going to close this because I'm no longer a stakeholder in this feature.

Unsure if it's useful for other people, but won't be for me personally. Feel free to re-open if you want a historical record, but I won't have access to this account for future responses.