Re: [PATCH v3 0/3] packfile URIs: support concurrent downloads

From: Jeff King <peff@peff.net>
Date: Jul 25, 2026, 09:09 UTC
Message-ID: <20260725090910.GA1438796@coredump.intra.peff.net>
In-Reply-To: <xmqqldb19evx.fsf@gitster.g>

On Thu, Jul 23, 2026 at 09:43:14PM -0700, Junio C Hamano wrote:

Show 5 quoted lines

> When merged into 'seen', this topic seems to cause t5550 to hang
> fairly consistently.  It is not surprising, considering that the
> topic adds roughly 240 lines to the test script in question.  It is
> entirely possible that we are seeing an existing breakage from
> another topic in 'seen' that is exposed by the additional tests.

I didn't get any hang locally, but running t5550 with --stress causes around half of the runs to fail immediately. That continues to be true with v4. So there is presumably some race condition still present.

The failing test is the big one (34) and the failing command is the "test -s $tmpfile" call. It looks like the pack has already been indexed (at least by the time I look at the on-disk state of a failed example).

I don't immediately see the issue, though. I could believe that extra load fakes out any sleep-based timing tricks, but it looks like the test tries to use FIFOs to do everything deterministically.

Diffing the overlap-first.trace file between a working case and a failing one, I see (skipping past uninteresting port differences) this hunk at the end:

  @@ -17,4 +17,5 @@
   <= Recv header: Connection: close
   <= Recv header, 0000000002 bytes (0x00000002)
   <= Recv header:
  -== Info: shutting down connection #0
  +== Info: end of response with 1048917 bytes missing
  +== Info: closing connection #0

So curl sees a hangup on the first connection (even though the second one hasn't even started yet!). I'm not sure why, though. There's nothing useful in the server.log file. I tried stracing the server process but it didn't show much of interest. Both cases write "ready" to first-ready, and then the success case immediately sees an accept() for the second connection. The failing case waits in accept() and then eventually calls SIGALRM (which is way after the failure happens; the test has already bailed and so the second connection never comes in).

So from the perspective of the server process, everything is fine, but curl complains that it didn't get all of the bytes. Weird. The strace shows both writing the first 1MB as expected. It's like the connection gets hung up for some reason, but I can't tell why or by whom.

-Peff