From 9a74d1d5df777fa56eb83f2fe75fbe01d9e91de7 Mon Sep 17 00:00:00 2001 From: Claude Date: Thu, 7 May 2026 01:11:12 +0000 Subject: [PATCH] fix(quic-interop): bump TRANSFER_TIMEOUT_SEC to 60s for multiplexing MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit aioquic multiplexing qlog showed: t=31424: still receiving STREAM frames t=31493: PTO timer expired t=31507: connection_closed (owner: local) We were still actively transferring when our 30s timeout fired. The multiplexing testcase generates many small files (3431 sim packets captured for the run) and download throughput on Mac+Rosetta is dominated by per-write filesystem overhead in the Docker volume mount. 60s gives enough headroom without making fast-completing tests slower. Doesn't fix any real protocol issue — just lets the test budget match the workload. If multiplexing still fails after this, the next investigation is the sequential `.map { it.await() }` pattern in runTransferTest: a single hung stream blocks the await chain even though others completed. https://claude.ai/code/session_01HcvfQq1ttPV9PkRoJb4nyT --- .../vitorpamplona/quic/interop/runner/InteropClient.kt | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/quic/interop/src/main/kotlin/com/vitorpamplona/quic/interop/runner/InteropClient.kt b/quic/interop/src/main/kotlin/com/vitorpamplona/quic/interop/runner/InteropClient.kt index 1ba9c1ad3..56ed408ae 100644 --- a/quic/interop/src/main/kotlin/com/vitorpamplona/quic/interop/runner/InteropClient.kt +++ b/quic/interop/src/main/kotlin/com/vitorpamplona/quic/interop/runner/InteropClient.kt @@ -55,7 +55,14 @@ private const val EXIT_FAIL = 1 private const val EXIT_UNSUPPORTED = 127 private const val HANDSHAKE_TIMEOUT_SEC = 10L -private const val TRANSFER_TIMEOUT_SEC = 30L + +// Multiplexing generates ~hundreds-to-thousands of small files; download +// throughput on Mac+Rosetta is dominated by Docker filesystem overhead +// per-write. 30s wasn't enough for the larger file counts; the qlog +// against aioquic showed us still actively receiving STREAM frames at +// t=31s when our local timeout fired. 60s gives more headroom without +// inflating turnaround for the cases that actually complete fast. +private const val TRANSFER_TIMEOUT_SEC = 60L fun main() { val role = System.getenv("ROLE") ?: "client"