Track CoroutineContext in Invocation tag

[AlessandroOddone]

This enables accessing the CoroutineContext where the method was called from an OkHttp interceptor.

Use cases:

• inspect elements of the CoroutineContext for logging/monitoring
• use runBlocking from Interceptor.intercept while preserving elements from the calling CoroutineContext

[JakeWharton]

I'm not super eager about this since suspend is meant to behave like a call adapter–entirely opaque to the actual execution of the call. I'm not opposed to passing the context to the invocation as a nullable thing, though.

We'll also need a test to ensure this works correctly.

[AlessandroOddone]

Updated. I added a kotlinCoroutineContext property to Invocation and a test.

[JakeWharton]

Right now the Kotlin dependency is optional, and this interacts poorly with that. Unfortunately we don't have a good test setup which covers this case. I still think is doable, but it probably mean we need to pass around things as Object internally.

[AlessandroOddone]

Right now the Kotlin dependency is optional, and this interacts poorly with that. Unfortunately we don't have a good test setup which covers this case. I still think is doable, but it probably mean we need to pass around things as Object internally.

I added a rule to exclude Kotlin dependencies from the classpath for test classes not named Kotlin*Test, and a test that ensures that CoroutineContext is actually not in the classpath when testing Invocation. This seems to work correctly in this scenario. I also validated this by integrating the snapshot in a Java-only project, without encountering any issues. Is my test case missing anything?

[danielrna]

Has this issue been resolved somewhere else please ? I really need to use the coroutineContext in my Okhttp interceptor. Thanks (: