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

Ted Nyman <[email protected]> writes:

> Packfile URI and dumb HTTP downloads stage packs at
> objects/pack/pack-<hash>.pack.temp so an interrupted transfer can
> resume. Opening that file in append mode forces every write to its
> current end. Two Git processes fetching the same pack into one object
> database can therefore append duplicate data and corrupt the pack.
> ...
> The tests cover resumption, a completed partial returning 416,
> overlapping 200 and 206 responses, unlinking the staging path while
> index-pack holds its descriptor, and a pre-existing .keep file. The
> unlink test does not require FIFOs, so it can exercise MinGW's sharing
> behavior even though the concurrent-download tests are skipped there.
>
> Changes since v2:
>
>   * Split the --index-pack-arg documentation and error-message cleanup
>     into a preliminary patch, as requested by Junio.
>   * Clarify why per-descriptor offsets keep overlapping writes safe and
>     why MinGW permits the shared staging path to be unlinked.
>   * Add a non-FIFO unlink-while-indexing regression test that can run on
>     MinGW.
>   * Rebase onto the current master.

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.

The CI run

  https://github.com/git/git/actions/runs/30045343889

is today's seen (excluding this topic) at 728e180b7b; it has
breakages in leak checking jobs from other topics, but does not see
t5550 hanging.

The CI run

  https://github.com/git/git/actions/runs/30048327878

is seen at 05d0dd408c that merges this topic on top of 728e180b7b
above.  It breaks the same leak checks, but in addition makes t5550
hang.

Can you help figure out what is going on?

Thanks.


PS. Recent CI runs on 'seen' started to spend so much time on static
    analysis (aka coccinelle) jobs, even though I do not think we
    acquired any new rules recently.  We probably need to figure out
    what is going on there, too.  There is something wrong for these
    CI runs that usually take ~40 minutes to spin for more than 4
    hours.