Ryosuke Hasebe

yes. ServerInteceptor is synchronous. A similar problem has been pointed out in gRPC-kotlin. https://github.com/grpc/grpc-kotlin/issues/223

I had the same issue in my environment. Please check when you have time. @mp911de 🙏 🙏

> The tracing context propagation code is written in a defensive way to avoid accidental propagation from the thread-local context Yes, there is certainly a probability of accidental propagation. It's...

Thank you for the detailed investigation. Keep pingBeforeActivateConnection enabled until it is fixed. (It seems to be difficult to fix because it is an asynchronous mechanism...)

I think this Issue proposal is very good. Therefore, I have implemented the following interceptor. I was also able to confirm that the [example code](https://github.com/grpc/grpc-kotlin/tree/39d0a7496cc88c44833506335dc9ef3117172714/examples/server) works. ```kotlin /** * https://stackoverflow.com/questions/53651024/grpc-java-async-call-in-serverinterceptor...

@harawata Thank you for reply. Yes, I think it can be avoided by devising a spring layer. However, in my opinion, incomplete instances should not be registered in DI. `mybatis-spring`...

To give you another example, `grpc-kotlin` supports customizing coroutine context. https://github.com/grpc/grpc-kotlin/issues/66 Being able to customize the context makes it much easier to propagate MDCs and Brave's Tracing. e.g. https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-slf4j/kotlinx.coroutines.slf4j/-m-d-c-context/index.html Please...

> This would be very helpful in regards to MDC context as mentioned above. Yes. This is very ver helpful for kotlin coroutine user.

@wplong11 Sorry for the late reply. of course! always ready to discuss :)

It seems good to add the following implementation specifically for the client side prepared statement. This will get the args part as `?`. e.g. `SELECT * FROM test WHERE id...