org.http4s.client.middleware.Retry consumes memory proportional to number of retries performed

Please consider this simple example:

name := "http4s-retry-leak"
version := "0.1"
scalaVersion := "2.13.2"
libraryDependencies += "org.http4s" %% "http4s-blaze-client" % "0.21.4"

import cats.effect.{ExitCode, IO, IOApp}
import cats.syntax.option._
import javax.net.ssl.SSLContext
import org.http4s.client.blaze.BlazeClientBuilder
import org.http4s.client.middleware.{Retry, RetryPolicy}
import org.http4s.{Method, Request, Uri}

import scala.concurrent.ExecutionContext.global
import scala.concurrent.duration._

object App extends IOApp {
  override def run(args: List[String]): IO[ExitCode] =
    BlazeClientBuilder[IO](global, SSLContext.getDefault.some).resource
      .use { client =>
        val retryPolicy: RetryPolicy[IO] = (_, _, _) => 5.millis.some
        val clientWithRetries = Retry[IO](retryPolicy)(client)
        val request =
          Request[IO](Method.GET,
                      uri = Uri.fromString("http://unknown-host").toOption.get)
        clientWithRetries.stream(request).compile.drain
      }
      .as(ExitCode.Success)
}

Each time the client makes an attempt, a series of new objects get allocated and retained. Here’s how it looks like after ~148k attempts:

And here you can find the heap dump itself: https://www.dropbox.com/t/GkFbbEMDge8uJdba

From what I understand, the issue might as well be in fs2, not in http4s, but I haven’t yet found a way to minimize the example further.

[Daenyth]

A sawtooth shape in the heap graph is very normal, it usually indicates that garbage collection ran and removed objects from the heap. If anything, that indicates that it’s maybe not a leak (where references are held and cannot be garbage collected), but rather memory pressure (lots of garbage being created and then cleaned)

[rossabaker]

I wonder whether this is fixed in 1.0, with its hotswap.