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

[Jeff King <peff@peff.net>]

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

> 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