From: Jeff King Date: Sat, 25 Jul 2026 10:10:43 GMT Subject: Re: [PATCH v3 0/3] packfile URIs: support concurrent downloads Message-ID: <20260725101043.GA2171844@coredump.intra.peff.net> In-Reply-To: <20260725100251.GA1933232@coredump.intra.peff.net> On Sat, Jul 25, 2026 at 06:02:51AM -0400, Jeff King wrote: > I wonder if we could just drop that "test -s" entirely. We'd _usually_ > see some bytes written before the second request starts. But it's OK if > we don't. It just means the test is working in the reverse order (the > second request may write its bytes first, and then the first one is the > one "overwriting" it). I.e., the two are symmetric from our perspective. Yeah, doing this: diff --git a/t/t5550-http-fetch-dumb.sh b/t/t5550-http-fetch-dumb.sh index dcb9667eeb..07aa218049 100755 --- a/t/t5550-http-fetch-dumb.sh +++ b/t/t5550-http-fetch-dumb.sh @@ -516,7 +516,6 @@ test_expect_success PERL,PIPE 'concurrent http-fetch --packfile cannot corrupt a read ready <&8 && test "$ready" = ready && test_path_is_file "$tmpfile" && - test -s "$tmpfile" && { GIT_TRACE_CURL="$TRASH_DIRECTORY/overlap-second.trace" \ GIT_TRACE_CURL_NO_DATA=1 \ @@ -533,9 +532,6 @@ test_expect_success PERL,PIPE 'concurrent http-fetch --packfile cannot corrupt a wait "$second_pid" && wait "$first_pid" && wait "$server_pid" && - test_grep "HTTP/[0-9.]* 200" overlap-first.trace && - test_grep "Range: bytes=[1-9][0-9]*-" overlap-second.trace && - test_grep "HTTP/[0-9.]* 206" overlap-second.trace && printf "keep\t%s\npack\t%s\n" "$packhash" "$packhash" | sort >expect && sort first.out second.out >actual && test_cmp expect actual && is enough to make it pass reliably under --stress for me. We have to drop the trace greps, because we don't actually know whether each request will use a range or not. We'd _usually_ see a range for the second one, but it's possible it might still see a zero-byte file. I guess we probably see a "200" reliably for the first request, but it's not all that interesting. We can leave the test_path_is_file check, because we open the file before making the request (it is only the actual writing of bytes that is racy). -Peff