KTOR-8455: Introduces the ability to preserve context with HttpClient. #4819
Conversation
WalkthroughThis change introduces an optional extension point for customizing the coroutine context used during HTTP request execution in the Ktor client engine. A new nullable property, Changes
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
ktor-client/ktor-client-core/common/src/io/ktor/client/engine/HttpClientEngineConfig.kt (1)
36-41: The implementation looks good, but the documentation could be more specific.The new
contextProviderproperty is a well-designed addition that enables preserving coroutine context across HTTP calls. However, the documentation is somewhat vague about its purpose and usage.Consider enhancing the KDoc to include:
- Specific use cases (like preserving MDC for logging)
- An example showing how to use it
- Clarification on when this context is applied during request execution
/** - * Allow preservation of additional context after processing operations. + * Allows preserving and injecting additional coroutine context during HTTP request execution. + * + * This is particularly useful for scenarios such as maintaining MDC (Mapped Diagnostic Context) + * for logging purposes, which would otherwise be lost when HTTP calls are made within an `async` block. + * + * Example usage: + * ``` + * HttpClient(Apache) { + * engine { + * contextProvider = { MDCContext() } + * } + * } + * ``` * * [Report a problem](https://ktor.io/feedback/?fqname=io.ktor.client.engine.HttpClientEngineConfig.context) */
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
ktor-client/ktor-client-core/common/src/io/ktor/client/engine/HttpClientEngine.kt(1 hunks)ktor-client/ktor-client-core/common/src/io/ktor/client/engine/HttpClientEngineConfig.kt(2 hunks)
🔇 Additional comments (1)
ktor-client/ktor-client-core/common/src/io/ktor/client/engine/HttpClientEngine.kt (1)
177-179: Implementation looks good and correctly preserves backward compatibility.The conditional logic to incorporate the additional context from the provider is well-implemented. It properly handles the nullable nature of the contextProvider and maintains the existing behavior when no provider is set.
There was a problem hiding this comment.
I think would fit better as an extension to the client plugin interface for manipulating the call coroutine context.
Perhaps a custom client hook, so it can be called like this from a client plugin:
on(CreateCallContext) { context: CoroutineContext, requestData: HttpRequestData ->
context + myCustomDebuggingContext(requestData)
}It would be nice to have a test in here as well with some real-world example usage.
|
❌ Junie can be launched only by a repository collaborator |
Subsystem
HTTP client and config
Motivation
Today, when using ktor's HTTP client, there is no provision to preserve CoroutineContext. Following the completion of the actual HTTP call made in an
asyncblock, any context that we might want to preserve is lost. For instance, MDC context, which is vital to logging in applications, cannot be preserved after the HTTPClient completes.Solution
The solution provides the ability to supply a coroutine context provider lambda when configuring the HTTPClient, via its configuration. This will be executed per request executed by the HTTP client, which would then inject the supplied CoroutineContext during the async call.