Johannes Rudolph

Last time I looked into these kinds of things, I think it was a combination of osgi, sbt-assembly, and sbt-reproducible-builds which created weird fields, but I cannot remember exactly. I...

As described in the original PR, the buffer size used to be calculated as ```scala val targetBufferSize = settings.maxOpenRequests - settings.maxConnections ``` The reasoning was that there can be one...

A few thoughts here: * One main point of HTTP/2 is that you only need a single TCP connection open and multiplex multiple requests on top of it. The benefit...

> I think we can proceed as follow I don't think we should do it like this. Especially, we don't want another entry point like `Http2()`. If we want to...

> What needs to be done when HTTP/2 is selected is to replace the code at `PoolInterface.apply`, to create an alternative connection flow that uses a single managed persistent HTTP/2...

> `OutgoingConnection.managedPersistentHttp2` and `NewHostConnectionPool` are compatible enough for it to work Which is not quite the case right now. `NewHostConnectionPool` is `Flow[RequestContext, ResponseContext]` while `managedPersistentHttp2` is `Flow[HttpRequest, HttpResponse]`. That's probably...

Also discovered a bug in the test itself and also a bug in sbt-scalafix... https://github.com/scalacenter/scalafix/issues/1828

fyi. this is still failing because the `validatePullRequest` task has problems aggregating correctly over modules that have no Scala 3 support and thus fails when encountering the scalafix modules.

In any case, it's not a blocker. It's somewhat unfortunate that some error cases fail more extremely than desired but it does not change the outcome a lot. Btw. the...

> Ill see if I have time for this, the fix doesn't seem that hard (just need to add an extra case where the exceptions are caught). I'll have a...