Arnout Engelen

ah, sorry for botching the reproducer ;) > Is it possible that the pekko test that was failing isn't actually providing a failure on the second subchannel? hmm, that seems...

OK, I can confirm our test still fails on 1.64 with `GRPC_EXPERIMENTAL_ENABLE_NEW_PICK_FIRST=true`, but there seems to be something else going on than I assumed earlier: In the pekko test we're...

Nice! Indeed pekko-grpc updated to v1.66.0 which should have this fix and default to `PickFirstLeafLoadBalancer`, and the integration tests are happy. Thanks!

The test succeeds, and I think it's generally intentional that this exception is logged. Instead of sending it to the console when running the test, though, we should probably capture...

Perhaps we could use `LogCapturing` (https://pekko.apache.org/docs/pekko/current/typed/testing-async.html#silence-logging-output-from-tests)

I _think_ the limitation identified here was the fact that we currently do not provide a way for the client to prevent the server from compressing the responses. This could...

I also suspect you might be better off with a lower-level API, but I'm pretty curious about your more exact use case :) 'Simply' passing the server socket to some...

I think this is caused by https://github.com/apache/commons-compress/pull/472

Checked the 1.1.0-M1 artifacts, those are now reproducible for 2.13, so indeed the fix seems to have the intended effect. I used: ``` sbt "set ThisBuild / net.bzzt.reproduciblebuilds.ReproducibleBuildsPlugin.reproducibleBuildsCheckResolver := DefaultMavenRepository;...

possibly related to https://github.com/lampepfl/dotty/blob/main/compiler/src/dotty/tools/dotc/config/OutputDirs.scala#L96