Implementing CoroutineScope in the generated services has proven to cause too many issues with ambiguous context / scope resolution.
Classes implementing CoroutineScope should have their life cycle bound to the start and stop of the unit of work they represent. Since service implementations generally have a life cycle that spans the life of the application, this makes them an Ill fit for implementing coroutine scope.
The original intent of implementing CoroutineScope was to give services a mechanism to provide an initial coroutine context for rpc calls. That initial context would be used to create a proper scope per rpc method invocation.
This pr introduces a new interface for services to implement that will still allow configuration of the initial rpc context. It will also allow less error prone usages of coroutines in service instances
Implementing
CoroutineScopein the generated services has proven to cause too many issues with ambiguous context / scope resolution.Classes implementing
CoroutineScopeshould have their life cycle bound to the start and stop of the unit of work they represent. Since service implementations generally have a life cycle that spans the life of the application, this makes them an Ill fit for implementing coroutine scope.The original intent of implementing
CoroutineScopewas to give services a mechanism to provide an initial coroutine context for rpc calls. That initial context would be used to create a proper scope per rpc method invocation.This pr introduces a new interface for services to implement that will still allow configuration of the initial rpc context. It will also allow less error prone usages of coroutines in service instances