What is the reason I have to manually `close()` an `HttpClient`? Why isn’t it designed so that the `...

# ktor

[Marc Knaup]

What is the reason I have to manually close() an HttpClient?
Why isn’t it designed so that the HttpClient is bound to a CoroutineScope and automatically closes when the scope is canceled/completed?
Isn’t this breaking structured concurrency (or at least requires workarounds)?

[Jorge R]

How should a CoroutineScope know that operation is needed? they are two different objects.
If you had an HttpClientCoroutineScope, then that could make sense. Maybe try to define a httpClientCoroutineScope fun wrapping coroutineScope fun?

[Marc Knaup]

I don’t know what you mean 🤔

coroutineScope {
   HttpClient().request(…)
}

The HttpClient should either be closed with the scope, or the HttpClient be closed automatically when the scope is manually canceled.

[Alexander Weickmann]

There is little guidance on the ktor docs on how to handle the HttpClient instance.
What we do is we create a holder object for the http client where we instantiate it as a val. This httpClient is never closed. It will stay there as long as the app runs.

[Marc Knaup]

That doesn’t work well with unit testing though.

[Marc Knaup]

I’m trying to find a good solution for other similar clients like API clients or workers.
Should they be closed? Or be launched into a scope? Ktor doesn’t seem to be a good reference here 🤔